...
...
...
...
...
...
Column | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||
|
Compiling with FCM
...
...
...
A quick introduction to FCM for OpenIFS users is available. A more detailed description of the 'fcm make' command is also available.
Build types
The supplied configuration files support 3 different build types:
Optimized build ('opt') - this is uses higher optimization and will generate the faster running model. Note that we do not always recommend the very highest optimization levels as this can sometimes cause the model to fail. The optimizations options are chosen conservatively to ensure the model will run successfully on a wide range of hardware and compiler versions. OpenMP is enabled in this configuration only. The user is free to increase optimization levels once the model is running successfully and we welcome feedback on best choice of compiler options.
Non-optimized build ('noopt') - this is intended for development and debugging. Optimization is set to -O0 and OpenMP is disabled. The model will run significantly slower. We recommend that when compiling OpenIFS for the first time, this build configuration is used as it will compile faster and be more stable.
Full debugging ('nansC') - this configuration is intended for debugging only. As well as setting the lowest optimization, -O0, it also enables array bound checking and initialisation of variables with special values that will trigger 'not-a-number' exceptions useful for trapping variables used before initialized. This will cause the model to run very slowly and is normally only used for short runs for tracing bugs.
Config files and variables
The FCM software uses configuration files identified by the suffix '.cfg'. They can be found in the directory oifs/make/fcmcfg
. The master configuration file for OpenIFS is in fcmcfg/oifs.cfg. It sets general configuration options for FCM, lets FCM know where the source code is and reads a single architecture and compiler specific configuration file. No compiler options are contained in the oifs.cfg file - these are always in the architecture specific configuration files.
The naming convention for these architecture specific files is: <architecture>-<compiler>-<build type>.cfg. For example, the file fcmcfg/x86_64-gnu-opt.cfg
would be for Linux 64bit with the GNU compilers and the optimized build. The user can copy and rename the files provided or create their own using an existing one as a template.
How to change build type.
...
...
...
...
...
...
...
...
...
...
changes the build type to the 'optimized' build. This means instead the file 'fcmcfg/x86_64-gnu-opt.cfg
' will be included by fcmcfg/oifs.cfg
instead of the file fcmcfg/x86_64-gnu-noopt.cfg.
Create your own config files
Suppose we wanted to run the model on MacOS X with the intel compiler and a optimized setting. We could set:
Code Block |
---|
export OIFS_ARCH=darwin
export OIFS_COMP=intel
export OIFS_BUILD=opt |
FCM would then read the file fcmcfg/oifs.cfg
which would expect to find a file called: darwin-intel-opt.cfg
. This file would need to be created by the user, we suggest copying one of the existing .cfg files as a template and modifying it to suit your purpose.
...
...
...
...
...
...
...
Change compiler options globally
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Examples
...
Changing options per file
The description above covers changing the compiler options globally, that is, for all files in the compilation. There may be instances when options for one or a few files need to be changed. For instance, in debugging where array bound checking is required for a handful of changed subroutines.
Changing options per file cannot be done using environment variables. There are several ways in which it can be done:
Edit the oifs.cfg file
The oifs.cfg file is the place to put all file specific options. Some can be found in this file already e.g.
Code Block |
---|
build.prop{fc.flags}[algor/internal/fourier] = $OIFS_FFIXED $OIFS_FFLAGS
build.prop{fc.flags}[algor/internal/lanczos/i2x.F] = $OIFS_FFIXED $OIFS_FFLAGS |
More information on the configuration file syntax for FCM can be found on the FCM Users Guide from the UK Met Office.
The first line above sets the build property 'fc.flags' (ie. fortran compiler flags) for the directory algor/internal/fourier
(under the 'src' directory). Note this sets compiler flags for all files in that directory.
The second line set the build property, compiler flags, for the specific file, algor/internal/lanczos/i2x.F. Note that all other files in this directory, unless changed elsewhere, will use the default compiler options as described above.
These statements are used to ensure F77 files are compiled correctly.
Example: you need to reduce the optimisation and include array bound checking on a specific file for testing. We suggest you make a copy of the oifs.cfg and add the line:
Code Block | ||
---|---|---|
| ||
build.prop{fc.flags}[ifs/module/yomtrans.F90] = -g -O0 -m64 -C -fconvert=big-endian |
and then compile using this new file:
Code Block |
---|
fcm make -f fcmcfg/oifs_copy.cfg |
Info |
---|
As this is a new .cfg file for FCM it will do a full build of the code from scratch. Any subsequent builds will be incremental - only compiling changed files. |
Using the 'include' statement
FCM configuration files support an 'include' statement. The oifs.cfg file uses this to include architecture and compiler specific information. If you need to include several lines changing the options for multiple files then another option would be to add an additional 'include' statement to point to a new file containing the build.prop lines you need. For example:
Code Block | ||
---|---|---|
| ||
include = $HERE/debug.cfg |
and then create the file fcmcfg/debug.cfg with the 'build.prop' lines you need.
Info |
---|
The $HERE variable is a special FCM specific variable that expands to the directory name containing the file. In this example the oifs.cfg and your debug.cfg are in the same directory. |
Inherited build
A third way to customize at the file level is through FCM's 'inherited build' mechanism. This simple but powerful facility is described in more detail in the HowTo modify and add new code. In brief this allows you to leave the current configuration and source untouched and 'use' or 'inherit' the OpenIFS configuration in a completely separate directory. This makes it easier to update the OpenIFS code for new releases and keeps any changes you make completely separate.
The reader is referred to the separate HowTo modify and add new code for examples on how to use it.
Recommendations
As described above, the build environment uses 3 types of build:
- Optimised
- Non-optimized
- Full debugging (nansC)
The compilation of OpenIFS can be changed is several ways:
...
For temporary changes when testing or debugging, setting environment variables (2) to override the compiler options is perhaps the simplest.
Once testing is finished and permanent changes are required, or if unsupported compilers are required, then copy an existing .cfg file and create your own. Any names can be used. For instance, if you wanted to have 2 configurations for the Intel compiler, one with the Intel MPI, the other with OpenMPI, then create files: x86_64-intel_impi-opt.cfg and x86_64-intel_ompi-opt.cfg and use the environment variable OIFS_COMP to switch between them. e.g. OIFS_COMP=intel_ompi (it's up to the user whether they want to create .cfg files for each build type; 'opt', 'noopt', 'nansC').
HTML |
---|
<script type="text/javascript" src="https://software.ecmwf.int/issues/s/en_UKet2vtj/787/12/1.2.5/_/download/batch/com.atlassian.jira.collector.plugin.jira-issue-collector-plugin:issuecollector/com.atlassian.jira.collector.plugin.jira-issue-collector-plugin:issuecollector.js?collectorId=5fd84ec6"></script>
|
...