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

[Martin Losch]

Hi Jean-Michel,

2.a looks like a good option to me. It’s most straightforward. Adding “useCAL=.TRUE.” to all set ups that are out there is backwards compatible to checkpoint63o (4years ago) and does not seem to me to a big deal. The other solutions seem to be overly convoluted.

Martin



> On 8 Feb 2017, at 21:11, Jean-Michel Campin <jmc at mit.edu> wrote:
> 
> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel