Scientific Computing

CMake can add interface linking to imported libraries. For example, a imported library obtained by find_package() or otherwise. Normally, this would work like the following example to say link “stdc++fs” to example imported library “imported::lib” for GCC older than 9.1.

if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 9.1.0)
  target_link_libraries(imported::lib INTERFACE stdc++fs)
endif()

Function target_link_libraries() should work, but does not always work for some projects with a configure time error. To workaround this issue if it arises, set target property INTERFACE_LINK_LIBRARIES directly like:

set_property(TARGET imported::lib PROPERTY INTERFACE_LINK_LIBRARIES stdc++fs)

Many CMake users have muscle memory for the three-stanza configure, build, test with CMake:

cmake -B build
# configure CMake and generate build files

cmake --build build
# compile and link binaries

ctest --test-dir build
# run program self-tests

This can be reduced to a single command for many programs:

ctest -S setup.cmake

where a single file setup.cmake is added to the project.

Command-line options like “-Dvar=yes” must be aggregated and passed along to ctest_configure(OPTIONS) in setup.cmake.

Capture the number of physical CPU cores available on a computer from Matlab:

function N = get_cpu_count()
%% get apparent number of physical CPU cores

N = maxNumCompThreads;
if N < 2  % happens on some HPC
  N = feature('NumCores');
end

end

Related: Python CPU count

Python can easily be used from CMake, perhaps to simplify test scripts for continuous integration. Python scripts are managed in CMakeLists.txt. First, find Python interpreter:

find_package(Python COMPONENTS Interpreter REQUIRED)

Then to run a simple Python script in a CMake test:

add_test(NAME MatmulPython
COMMAND ${Python_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/matmul.py
)

To use PyTest:

add_test(NAME MatmulPython
COMMAND ${Python_EXECUTABLE} -m pytest ${CMAKE_CURRENT_SOURCE_DIR}
)

That will look under tests/test*.py by default.

From the project directory:

cmake -B build -S .

-S .

relative path to CMakeLists.txt e.g. -S src

This generates the makefile, but does not compile anything, since CMake is a build script generator.

Compile:

cmake --build build --parallel

--parallel

Compile code in parallel, if possible.

This uses the appropriate compilers and linkers to generate the executables and libraries.

Execute self-tests you’ve defined with add_test() in CMakeLists.txt:

ctest --test-dir build -V

If that’s too verbose, try:

ctest --test-dir build --output-on-failure

For faster testing by defaulting to running multiple tests in parallel, set CTEST_PARALLEL_LEVEL environment variable.

Octave uses startup.m persistent user settings like Matlab. To keep Matlab compatibility, put Octave-specific startup commands and plotting defaults into ~/.octaverc, which sets default parameters for all GNU Octave sessions.

suppress_verbose_help_message(1)
page_output_immediately(1)
page_screen_output(0)
crash_dumps_octave_core(0)
sigterm_dumps_octave_core(0)
sighup_dumps_octave_core(0)

if isfile('~/Documents/MATLAB/startup.m')
  source('~/Documents/MATLAB/startup.m')
endif

*_dumps_*

eliminate nuisance octave-workspace files that appear when Octave is Ctrl+c exited or crashes.

page_output_immediately(1)

make Octave print immediately like Matlab.

if exist

use startup.m file like Matlab.

Set plot defaults: useful for HiDPI systems, control Octave default plot text size of axes and titles, useful for HiDPI systems by adding to “~/.octaverc”:

set(0, "defaultaxesfontsize", 16)
set(0, "defaultlinelinewidth", 2)

adjust 16 to produce the most appealing text labels in:

• axes tick labels
• legend key
• title text

defaultline is the root category for lines, so defaultlinelinewidth is not a typo.

Speedup Octave start (without GUI): don’t autoload Octave packages

Tell current matplotlibrc location:

python -c "import matplotlib; print(matplotlib.matplotlib_fname())"

matplotlibrc location priority

Help end users have the same plotting experience by putting a matplotlibrc file in the Python project directory that users run your script from.

CTest CDash scripts can use the function ctest_empty_binary_directory to recursively remove a CMake build directory to avoid hidden state between test runs in an overall build-test cycle. However, this function will cause the overall CTest run to return a non-zero error code if CMakeCache.txt isn’t present in the build directory. This is confusing in a CI system particularly. While we do appreciate this safety feature over simply using file(REMOVE_RECURSE), it’s necessary to enclose in if() statements like below to avoid false errors.

if(EXISTS ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt)
  ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})
endif()

# ctest_start(), etc.

CMake build targets are added by “add_[executable,library,custom_target]” commands. Targets can be dynamically set by arbitrarily complex foreach(), if(), etc. logic. A list of tests enabled is retrieved by the BUILDSYSTEM_TARGETS directory property.

The variable “target_names” contains all the target names previously added in the CMakeLists.txt in the DIRECTORY scope.

get_property(target_names DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY BUILDSYSTEM_TARGETS)

get_property(test_names GLOBAL PROPERTY BUILDSYSTEM_TARGETS) will return an empty list–DIRECTORY scope must be used.

Linux modules are often used by HPC systems allow using more current versions of software than are in the default system repositories. A typical approach is to create an .sh file for a particular job type. To avoid unexpected conflicts or hidden state, load only the modules necessary for a particular project.

Many modules are typically available, listed by:

module avail

The currently loaded modules are listed by:

module list

Load recent GCC:

source gcc.sh

with gcc.sh like:

module load gcc

export CC=gcc CXX=g++ FC=gfortran

Determine available GCC versions:

module avail gcc

Load Intel oneAPI:

source oneapi.sh

with oneapi.sh like:

module load intel-oneapi

export CC=icx CXX=icpx FC=ifx
export MPI_ROOT=$I_MPI_ROOT

Determine available Intel oneAPI versions:

module avail intel-oneapi

Some HPC systems have a too-old GCC version defaulting for Intel oneAPI, which can be fixed by setting GCC toolchain.

Cray PE programming environment allows easy switching of compilers for developing and running applications on Cray supercomputers. Use the Cray compiler wrappers cc, CC, and ftn instead of directly referencing the compiler backends gcc, g++, and gfortran.

In CMake script, detect if Cray PE is being used, regardless of compiler backend by detecting if environment variable PE_ENV or CRAYPE_VERSION is set.

if(DEFINED ENV{CRAYPE_VERSION})
  message("Cray PE detected")
endif()