[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