Programming

Building OpenMP code is actually possible using Apple Clang that comes default with macOS’s Xcode! Although Apple does not build the OpenMP library, the compiler still supports it. In this post, I demonstrate the procedure necessary to include OpenMP in your build, both with the new support in CMake 3.12, as well as how it would be done without it.

The next version of the premier CUDA/OpenMP fitting program for HEP analysis, GooFit 2.0, has been released. GooFit is now easy to build on a wide variety of Unix systems, and supports debuggers and IDEs. GooFit is faster, has unit tests, and working examples. More PDFs and examples have been added, as well as newly released example datasets that are downloaded automatically. GooFit now has built in support for MPI, and can use that to deploy to multiple graphics cards on the same machine. A new command line parser (CLI11) and drastically improved logging and errors have made code easier to write and debug. Usage of GooFit specific terminology is now reduced, using standard Thrust or CUDA terms when possible, lowering the barrier for new developers. A new Python script has been added to assist users converting from pre 2.0 code.

The file structure of GooFit and the build system have been completely revamped. The fake nvcc features have been removed, as have the rootstuff copies of ROOT classes. PDFs are now organized by type and compile and link separately. Multiple PDF caching support has improved. The build system now uses CMake and manages external libraries.

A new feature of the CMake build system is GooFit Packages, which are complete packages that can be added to GooFit and built, allowing analysis code to live in a separate location from GooFit, rather than the old method of simply forking GooFit and adding your analysis manually. A GooFit Package can be made into an example trivially. See this package for an example.

GooFit 2.0 will receive continuing support while development on GooFit 2.1 presses on.

Links

GooFit on GitHub • GooFit webpage • API documentation

CLI11, a powerful library for writing command line interfaces in C++11, has just been released. There are no requirements beyond C++11 support (and even <regex> support not required). It works on Mac, Linux, and Windows, and has 100% test coverage on all three systems. You can simply drop in a single header file (CLI11.hpp available in releases) to use CLI11 in your own application. Other ways to integrate it into a build system are listed in the README.

The library was inspired by the Python libraries Plumbum and Click, and incorporates many of their user friendly features. The library is extensively documented, with a friendly introduction, a tutorial filled (in progress) GitBook, and more technical API docs.

I often see perfect forwarding listed for constructor arguments, but not usually for functions with a return or methods. Here is my solution for a method of class Cls:

template<typename ...Args>
static auto method(Cls* cls, Args &&  ...args)
  -> typename std::result_of<decltype(&Cls::method)(Cls, Args...)>::type {
    return cls->method(std::forward<Args>(args)...);
}

This is useful if you want to call protected methods from a “helper” friend class, for example, to expose them to tests without having to require GoogleTest/GoogleMock to be available for regular users.

This is a guide to setting up Lmod (lua environment modules) on a CentOS system. I’ve used a similar procedure to set them up on a Mac, as well, so this is still a useful guide to the workings of Lmod if you use a different system; mostly paths will change. On a Mac, you’ll want to install Lmod from the science tap in brew. There are several good pages covering environment modules (TCL version), but not many that use the newer Lua syntax. This document aims to fill that role.

About ten years ago, Guido Van Rossum, the Python author and Benevolent Dictator for Life (BDFL), along with the Python community, decided to make several concurrent backward incompatible changes to Python 2.5 and release a new version, Python 3.0.

The every-three-year cycle has changed the development of C++; we are now getting consistent releases somewhere in-between the major and minor releases of old. The 2017 release may be called minor by some, with a huge portion of the planned improvements being pushed back another 3-6 years, but there were several substantial changes in useful areas; it is much more impactful than C++14, for example. This almost feels like a lead-in release to C++20.

The std::variant, std::optional, and std::any additions to the standard library are huge, and can restructure the way you program (and are available for older C++ releases through Boost and other libraries).

Unlike C++11, this is a minor release, focused mostly on improvements on top of C++11 changes, with very little that one could call “new”. C++14 feels a little more natural than C++11 by expanding the usage of features and implementing common sense additions that were missed in the original C++11 release. There were also quite a few bug fixes; several of these were backported into C++11 mode in compilers.

Also, while C++11 is always available in ROOT 6, C++14 requires a flag and compatible compiler, so C++14 features are often unavailable. The Conda-Forge ROOT package has C++17 enabled.