[MITgcm-devel] using pkg/exf without pkg/cal

[Jean-Michel Campin]

Hi,

Regarding problem (1), i.e., allowing to compile pkg/exf without pkg/cal,
I am going to implement something like 1.c but defining a new type of
dependence so that it does not not affect the other pkg dependencies.

And feeling more in favor of solution 2.a but would appreciate any feedback.

Cheers,
Jean-Michel

On Tue, Feb 07, 2017 at 12:19:09AM -0500, Jean-Michel Campin wrote:
> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel