[Mitgcm-support] Re: KPP (c30) bug

[mitgcm-support at dev.mitgcm.org]

Alistair, the difference in the two approaches is one of coding philosophy.
You attempt to impose a strict set of rules for packages and to maintain
maximum control within the baseline code while the approach I suggest gives
more options and hence more responsibility to package developers.  The final
decision is of course yours and I will code accordingly, but here are a few
more thoughts on these issues.

>> The problem with allowing PKG1_OPTIONS.h and PKG2_OPTIONS.h to
>> change ALLOW_CONVECT is that the order in which you call packages
>> matters. Another package might turn it back on again. 'cpp'
>> isn't upto the task.
>>
>> Remember that convection can be turned off with adjFreq=0 so you
>> don't have to recompile the model if you accidentally have it
>> compiled.
>>
>> I think we are making the mistake of treatng CPP_OPTIONS.h more
>> like a runtime parameter file rather than compilation configuration.

Agreed, but the reality is that many of the options that need to be turned on
or off (including convection in older versions of the code) can at present
only be done using CPP flags.  It is conceivable that this will not be the
case in the future, but to proceed right now packages need a way to modify
baseline code CPP options.  As the code evolves, PKGX_OPTIONS.h can become
more and more robust until ultimately they are all reduced to

    PKGX_OPTIONS.h
    #define ALLOW_PKGX

which would then be exactly equivalent to what you advocate.

>> Absolutely no - I bet you will be the first of thousands to
>> forget to copy data.gmredi and burn 100 hours of CPU and
>> only then realise the file was missing. Having a list
>> in a file like data.pkg is safe and understandable.
>> CPP_OPTIONS.h is not meant to do this job. CPP_OPTIONS.h
>> is really for optimizing out unwanted code. The default
>> mode ought to be that everything is compiled and nothing
>> is selected in data.pkg. That's provides the fastest way
>> to set up the model simply be editing one file and not
>> recompiling.
>>
>> "data.pkg" could go back in "data" but I thought it would be
>> easier to separate them until data is reduced further
>> as more packages are added.

For code efficiency and size, it does not make sense to control some packages
by runtime parameters.  But I have no problem with the data.pkg concept
because it can easily be ignored by packages that do not need it.  For
consistency though, I vote that data.pkg should go back inside data since it
is part of the baseline MITGCMUV code.

Dimitris