[MITgcm-devel] using pkg/exf without pkg/cal
Jean-Michel Campin
jmc at mit.edu
Tue Feb 7 00:19:09 EST 2017
Hi All,
I made some changes in the code to allow to use pkg/exf without pkg/cal.
I think this is useful for cases where the model time-step is not an integer
number of seconds (idealized/high-res setup with seaice or obcs) or in case
all the forcing fields are constant in time (all {FLD}period = 0).
The major difference between useCAL=F and useCAL=T is that the starting-time
has to be specified directly (in data.exf) whereas with useCAL=T, it is set
according to {FLD}startdate1 and {FLD}startdate2.
I've just added some check+stop (to make it safer) for the cases where
a) {FLD}startdate1 or {FLD}startdate2 are non-zero (=default)
with {FLD}period > 0 but useCAL=F
b) {FLD}StartTime is specified in data.exf but useCAL=T
For some of you who maintains pieces of code that use pkg/exf (e.g., Oliver):
I kept a version of EXF_GETFIELD_START (with unchanged argument list)
for backward compatibility but it would be nice to transition to the new
S/R (one more "F") EXF_GETFFIELD_START so that we could remove the old
version in the near future.
Matt (and other pkg/bling developers):
I made few changes in the USE_EXFCO2 code of pkg/bling (I hope it's OK), since
the setting of apco2StartTime was missing. If you feel that the call to
EXF_GETFFIELD_START (that I put in bling_readparms.F) would be better in
bling_init_fixed.F, this could be moved easily.
Now the problem: Currently, it's not so easy to use pkg/exf without pkg/cal:
1) Compiling level:
current pkg dependency rules (pkg/pkg_depend) does not allow to compile
pkg/exf without pkg/cal.
a) One solution is to change "pkg/pkg_depend" (to remove the line 39:
exf +cal
but this does not facilitate the task of maintaining previous set-up with
up-to-date MITgcm code. Also not sure that the 1rst running error would be
and how clearly it would point to this missing compiled pkg.
b) Otherwise, one can by-pass this rule by using a specific dependency
rules file (instead of using pkg/pkg_depend) but not very straitforward for
a user point of view.
c) we could also change how dependency rules are enforced (in genmake2),
with a disable pkg in packages.conf (e.g., "-cal") taking over a positive
dependency rule (e.g.: "exf +cal").
The rule will still apply (as now) when pkg cal is not listed in packages.conf,
compiling pkg/cal if pkg/exf is to be compiled.
Since the memory footprint of pkg/cal is small, not so much an issue if,
by default, the rule is maintained regarding pkg/exf dependence.
2) Current setting of run-time params "useCAL", in packages_boot.F, line 188:
> #ifdef ALLOW_CAL
> IF (useEXF) useCAL = .TRUE.
> #endif
overwrites the "data.pkg" selection. I think this should be changed to allow
not to use pkg/cal with pkg/exf, since it's now possible.
a) we could just set useCAL like all other pkg run-time switch. But again,
the same issues as above regarding solution 1.a, with a little improvement in
error tracking if pkg/cal is already compiled.
b) we could set the default useCAL=T if both pkgs are compiled (ALLOW_CAL
& ALLOW_EXF) to be changed (or not) according to data.pkg settings.
This might ensure an easy transition when updating old set-up, but in case
pkg/exf is compiled but not used (useEXF=F), this will switch on pkg/cal
(useCAL=T) by default, which is different from previously (e.g., a couple
of "data.pkg" in verification experiments will need an update).
Also not very transparent for a new user (a rule for some pkgs but a different
one for pkg/cal ?).
c) reading 2 times "data.pkg" might help, but it does not simplify the code
and again no very clear rules for new user.
Any suggestions ?
Cheers,
Jean-Michel
More information about the MITgcm-devel
mailing list