The information on this page is not complete

Ways to modify OpenIFS

There are several ways in which code changes to OpenIFS could be managed:

  1. Edit code in the oifs/src directory directly (not recommended).
    Code changes can be hard to track and integrating new versions of the model becomes difficult.
  2. Place OpenIFS source in a version control system (e.g. subversion or git) and edit the code in oifs/src.
  3. Leave code in oifs/src 'as-is' and place modified or new code in new directories (recommended)
    This has the advantage that multiple code developments can be maintained in separate directories; code changes are easy to see and integrating new versions of the model source straightforward. A version control system can also be used.

We recommend maintaining all code changes outside the main oifs/src directory. It makes use of a facility provided by the FCM build software called 'inherited builds'. This is explained below in a series of examples.

 

 

 The example configuration files for FCM can be downloaded from....

Inherited builds with FCM

In essence an inherited build is where the build (i.e. compilation) settings for OpenIFS are not altered but are used or inherited by a new FCM configuration file placed in a separate directory. The new FCM configuration file only needs to specify what's different about the build, either the sources or compilation settings. The rest of the information is obtained by telling FCM to look at the OpenIFS configuration. A user may have a number of these separate configuration files each in separate directories for developing or testing independent code changes.

 Note! Before running these examples, make sure you have built the model by using the 'fcm make' command in the 'oifs/make' directory in the normal way.

Example1: Modifying compilation options

HowTo customise compiling OpenIFS explains how environment variables and editing the configuration files can alter the compiler settings for OpenIFS. In this simple example, an inherited build is used to achieve the same effect by creating a separate configuration file.

The advantage of this approach is that the source code and configuration files of OpenIFS are left unaltered.

Create directories for your own configuration files and source code. For example, create 'oifs/mymake' in which to put your own configuration files and 'oifs/mysrc' to put your own source code:

% cd oifs
% mkdir mysrc mymake
% ls
COPYING  ChangeLog  INSTALL  LICENSE  NOTICE  README  html  make  mymake  mysrc  src  t21test
% cd mymake

The OpenIFS source code is in 'src' with the compilation configurations files used by the FCM build software in 'make/fcmcfg'.

In the 'oifs/mymake' directory, create a file called 'change-fcflags.cfg' with the following content:

use = ../make
include = ../make/fcmcfg/oifs.cfg
#  Add array bound checking to some routines for debugging
build.prop{fc.flags}[ifs/phys_radi/uvclr.F90] = $OIFS_FFLAGS -fcheck=bounds

Now run the fcm command to build the model with this change:

% fcm make -v -f change-fcflags.cfg
[init] make                # 2013-02-25 17:20:06Z
[init] make config-parse   # 2013-02-25 17:20:06Z
[info] config-file=/openifs/inherit_tests/oifs/mymake/change-fcflags.cfg
[info] config-file= - /openifs/inherit_tests/oifs/make/fcmcfg/oifs.cfg
[info] config-file= -  - /openifs/inherit_tests/oifs/make/fcmcfg/x86_64-gnu-opt.cfg
[done] make config-parse   # 0.3s
[init] make dest-init      # 2013-02-25 17:20:06Z
[info] dest=nagc@elvira:/openifs/inherit_tests/oifs/mymake
[info] mode=new
[info] use=/openifs/inherit_tests/oifs/make
[done] make dest-init      # 0.0s
[init] make build          # 2013-02-25 17:20:06Z
[info] sources: total=2192, analysed=0, elapsed-time=0.6s, total-time=0.0s
[info] target-tree-analysis: elapsed-time=13.3s
[info] compile    0.2 M uvclr.o              <- ifs/phys_radi/uvclr.F90
[info] link       1.7 M master.exe           <- programs/master.F90
[info] compile   targets: modified=1, unchanged=2070, total-time=0.2s
[info] compile+  targets: modified=0, unchanged=626, total-time=0.0s
[info] ext-iface targets: modified=0, unchanged=1247, total-time=0.0s
[info] install   targets: modified=0, unchanged=120, total-time=0.0s
[info] link      targets: modified=1, unchanged=0, total-time=1.7s
[info] TOTAL     targets: modified=2, unchanged=4063, elapsed-time=25.3s
[done] make build          # 26.3s
[done] make                # 26.6s

Notice the lines:

[info] compile    0.2 M uvclr.o              <- ifs/phys_radi/uvclr.F90
[info] link       1.7 M master.exe           <- programs/master.F90

showing that FCM has noted the change in the compiler options for the file uvclr.F90, recompiled it and relinked the main executable.

If you now check the contents of this directory, you'll see:

:% ls -R
build  change-fcflags.cfg
./build:
bin  o
./build/bin:
master.exe
./build/o:
uvclr.o

As in the main 'make' directory, FCM has created a 'build' subdirectory which in this case only contains the object file of the routine uvclr and a new executable. You now have the original executable in 'oifs/make/build/bin/master.exe' and this modified one for testing/debugging.

Experiment with this example by adding additional lines in the change-fcflags.cfg file and verify that the 'fcm make' command shows those routines being recompiled.

To verify the new compiler options are being used add the -vv flag to the fcm make command to see all output i.e. fcm make --v

 

 

<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>