The information on this page is not complete
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 or new compiler configurations files.
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.
The files for these examples can be downloaded from....
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.
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
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 and do not need any environment variables to be set.
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
As usual 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
The 'use
' statement tells FCM that a pre-compiled version of OpenIFS exists in the directory '../make
'. This pre-compiled version is 'inherited' through the 'use
' statement. All targets (i.e. the object files), source and compilation settings are inherited.
Now run the fcm command to build the model with this change (make sure you have already compiled OpenIFS in the normal way in the oifs/make
directory as this relies on the .o files being available):
% fcm make -v -f change-fcflags.cfg [init] make [init] make config-parse [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 [info] use=/openifs/inherit_tests/oifs/make [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
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.
Example 3: Adding new code