...
Why? The reason is that the code does not have enough information to determine where the subroutine 'newsub' comes from. As it's not a module (no USE statement), nor has an explicit interface (no #include "newsub.intfb.h") FCM will assume it comes from an external library.
We can correct the problem in two ways.
Solution 1. The preferred way is to add an explicit interface for the subroutine call making it clear the source code is not from an external library. This also has the advantage that the compiler can check arguments passed to the subroutine are correct. Interface files for subroutines are generated automatically by FCM and do not need to be created by the user.
| Code Block | ||
|---|---|---|
| ||
#include "su0yoma.intfb.h" #include "su0yomb.intfb.h" #include "newsub.intfb.h" ! ------------------------------------------------------------------ call newsub |
Building the model now works:
| Code Block | ||
|---|---|---|
| ||
% 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:
| Code Block |
|---|
use = ../make
build.source = $HERE/../mysrc
build.ns-incl = newsrc algor ifsaux ifs surf trans openifs programs/master.F90
build.prop{ns-dep.o}[programs/master.F90] = newsrc algor trans surf ifs ifsaux openifs
build.prop{fc.flags}[ifs/control/cnt0.F90] = -g -O1 -fcheck=bounds |
The statement 'build.prop{ns-dep.o}' means the file 'programs/master.F90' depends on the object files (.o) created from the source in the directories listed. By adding the entry 'newsrc' to the list (see the original statement in oifs/make/fcmcfg/oifs.cfg) this will force FCM to compile all the source code it finds in the newsrc directory. If this behaviour is not desired the statement build.ns-excl can be used to list directories and/or files that should be excluded from the compilation.
Tips
We hope these examples serve to illustrate how to alter and add to the OpenIFS source code using FCM and although simple, the examples show the basics on which to build more complex changes. Whether you choose to use inherited builds or work with copies of the code is largely down to personal preference but we offer a number of suggestions to make life easier:
- 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 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.
Further reading and help
A more detailed description of the FCM's 'make' command and the syntax of the configuration files can be found in the FCM User's Guide provided by the UK Meteorological Office. Note that OpenIFS only uses the 'make' command and not any other FCM subcommands.
Additional help can be found in the compiling and FCM OpenIFS Frequently Asked Questions page.
The OpenIFS forums can be used to ask questions to the OpenIFS community and support team.
Any questions or problems can also be sent direct to the OpenIFS support team at: openifs-support@ecmwf.int.
| 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> |
...