Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column

Ways to modify OpenIFS

We do not recommend that the source code in the oifs/src directory is edited directly as this can make it difficult to track changes and update to new versions. We recommend all code changes are maintained outside the main src directory. There are several ways in which code changes to OpenIFS could be managed:

Copy entire source

Copy the entire oifs/src to (for example) oifs/mysrc and work on the copy. The build configuration files can also be copied if required to, say, oifs/mymake. For instance you might make a new version of oifs/make/fcmcfg/oifs.cfg for your own changes.

Multiple copies of the src directory could be used for different experiments.  The use of a version control system is recommended to track changes. The difficulty with this approach is the full source needs to be copied which makes integrating changes different and changed files are hard to see.

Copy only changed/new source

Leave code in oifs/src 'as-is' and place only modified or new code in separate directories but link to pre-compiled code in oifs/make.  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.

This makes use of a facility provided by the FCM build software called 'inherited builds'. This is explained below in a series of examples.

Inherited builds with FCM

In essence an inherited build is one in which a pre-build (i.e. compilation) of OpenIFS is 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 already  compiled OpenIFS. A user may have a number of these separate configuration files each in separate directories for developing or testing independent code changes.

Column
width250px

 

 

Panel
bgColorwhite
titleBGColorlightlightgrey
titleOn this page
Table of Contents
maxLevel3
indent4px
stylesquare
Panel
bgColorlightcyan
titleBGColorlightskyblue
titleDownload examples

These examples can be downloaded as tarfile.

Save the tarfile in your oifs directory, where the main OpenIFS tarfile was unpacked. This tarfile will create several directories: mymake, mysrc1, mysrc2 and mysrc3.

Inherited builds with FCM

...

oifs_inherit_examples.tar.gz.

Save the tarfile in your oifs directory, where the main OpenIFS tarfile was unpacked.

This tarfile will create several directories: mymake, mysrc1, mysrc2 and mysrc3.

Note

 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 as these examples rely on that build being present

...

Info

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 --vvv or look in the FCM log file which can be found in the file .fcm-make/log.

Example 2: Editing existing code

In this example, we'll build on the previous example and edit an existing source file. First make a new directory to hold the modified source code and copy a source file:

...

As in example 1, the 'use' statement tells the build command FCM where to find the pre-compiled OpenIFS and all that's needed here are the changes. In this case, we now need to tell FCM where our new source code is using the 'build.source' statement - the special fcm $HERE variable means "the directory which contains this configuration file". As above, weWe'll also change the compiler options for this file. Note we don't need to include the oifs.cfg file as in the previous example, as this file doesn't contain any references to the OIFS_FFLAGS variable.

...

Code Block
titleFCM output (shortened)
% fcm make -v -f new-src.cfg
[init] make                # 2013-02-26 17:43:46Z
[init] make build          # 2013-02-26 17:43:46Z
[info] analyse  0.0 newsrc/newsub.F90
[info] analyse  0.0 ifs/module/yemct0.F90
[info] analyse  0.0 ifs/control/cnt0.F90
[info] sources: total=2193, analysed=3, elapsed-time=0.5s, total-time=0.0s
[info] target-tree-analysis: elapsed-time=13.4s
[info] compile    0.0 M newsub.o             <- newsrc/newsub.F90
[info] ext-iface  0.0 M newsub.intfb.h       <- newsrc/newsub.F90
[info] compile    0.0 M yemct0.o             <- ifs/module/yemct0.F90
[info] compile+   0.0 M yemct0.mod           <- ifs/module/yemct0.F90
[info] ext-iface  0.0 U cnt3.intfb.h         <- ifs/control/cnt3.F90
[info] compile    0.0 U cnt2.o               <- ifs/control/cnt2.F90
[info] ext-iface  0.0 U cnt0.intfb.h         <- ifs/control/cnt0.F90
[info] compile    0.1 U cnt3.o               <- ifs/control/cnt3.F90
[info] compile    0.1 M cnt0.o               <- ifs/control/cnt0.F90
[info] link       1.7 M master.exe           <- programs/master.F90
[info] compile   targets: modified=3, unchanged=2069, total-time=0.3s
[info] compile+  targets: modified=1, unchanged=625, total-time=0.0s
[info] ext-iface targets: modified=1, 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=6, unchanged=4061, elapsed-time=25.2s
[done] make build          # 25.8s
[done] make                # 26.0s

The compilation now succeeds. Note that as well as analysing the new code, FCM has also compiled newsub.F90 and created the interface for it, newsub.intfb.h (found in the build/include subdirectory).

Solution 2. Another way to correct the problem is to explicitly tell FCM that the master program depends on the code in our new directory. If you have many new source files and they do not use interface statements you will need to use this approach instead (or as well as - we recommend using interfaces wherever possible).

In this case, rather than edit cnt0.F90 (though its still preferable to include the #include "newsub.intfb.h" statement in cnt0.F90), add another statement to the FCM configure file:

...

  • If not using inherited builds, always work with copies of the code from the main 'src' directory, never edit the files in src directly - unless you are using a source versioning system, tracking changes and integrating new versions of the code is difficult.
  • Inherited builds work well with small and large code changes and help to separate code changes and additions. Any code patches to the main src are automatically compiled in linked with inherited builds whereas if you maintain separate copies of the source you'll need to update every copy.
  • Only copy the FCM configuration files from make/fcmcfg if you need to and then only oifs.cfg rather than the hardware and compiler settings. It helps to keep all hardware & compiler specific configuration files in one place (ie. make/fcmcfg) and either make links to them from other directories or, if you are not using inherited builds, use 'include' statements in your modified oifs.cfg file to always refer to them in the default location make/fcmcfg.

...