When using the testsuite, there are some parameters that can be customized for your system. In particular, the use of environmental modules and the use of a batch scheduler. The former allows the use of multiple compilers vendors and versions, and libraries (e.g. cuda versions). The later provides exclusive access to computation, and it differentiates development environment with running environments.
If you want to know how to use these elements in the context of the makefile, please refer to our makefile documentation.
According to our file structure explained in our repository section, inside the sys folder you will find a subfolder called systems. The purpose of this folder is to store system definition files. These files contain the definitions to customize the testsuite to the running environment.
In order to enable system-dependent options in the makefile, you must specify the SYSTEM=sysname option with the make command. This option enables a lookup of the particular system definition file located in the sys/systems folder. In order to create a new sysname a file with the same filename must be created, and with extension .def . For example. if your system name is MySystem, you need to create a file named MySystem.def inside of the sys/systems/ folder. Then you will use the SYSTEM=MySystem option in the make command. Notice that this name is case sensitive.
Following is a list of variables that are used inside of the system.def definition file.
|BATCH_SCHEDULER||This corresponds to the batch scheduler command that is pre-appended to the execution of the execution of a tests. For example, if your system uses aprun, you will use
|CUDA_MODULE||This option is for loading Cuda environmental modules. This corresponds to the module used if a particular version of Cuda wants to be loaded before compilation or execution of a tests. For example
|C_COMPILER_MODULE||This option is for loading the C compiler modules. This corresponds to the module used if a particular compiler vendor and version needs to be loaded before compiling or running a tests. For example
|CXX_COMPILER_MODULE||This option is for loading the C++ compiler modules. This corresponds to the module used if a particular compiler vendor and version needs to be loaded before compiling or running a tests. For example
|C_VERSION||This option is mainly created to add version information to the log files. This allows running the tests with multiple compiler versions and still being able to differentiate them when processing the log files. You can use a particular version number, or a command that results in the version number. For example `C_VERSION = xlc -qversion|
|CXX_VERSION||This option is mainly created to add version information to the log files. This allows running the tests with multiple compiler versions and still being able to differentiate them when processing the log files. You can use a particular version number, or a command that results in the version number. For example `CXX_VERSION = xlc++ -qversion|
Be aware that we use the
module load command for loading the environmental modules. If there are modules that conflict with the newly loaded module, and the environmental module software does not support implicit switch of modules, this could cause the execution of the testsuite to fail.
As some of this variables depend on the compiler, it is sometimes necessary to change the value depending on the compiler being used, specially when you intend to use this testsuite to check multiple compiler’s compliance with your system. Hence, in order to solve this issue, it is possible to use the Makefile ifeq syntax to solve this issue. For example:
# GCC compiler ifeq ($(CC), gcc) C_COMPILER_MODULE = gcc/7.1.1-20170802 C_VERSION = 7.1 endif # IBM XL compiler ifeq ($(CC), xlc) C_COMPILER_MODULE = xl/20180125 C_VERSION = xlc -qversion | grep 'Version: .*$$' | sed 's/Version: //g' endif
Here are the steps to add a new system