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

[mitgcm-support at dev.mitgcm.org]

>> Can you explain this. Every option we use has run-time control
>> (some, like momAdvection, need to be fixed). Is there something
>> in KPP that is only CPP'd in the main code?

For KPP, the CPP options that matter are convection, GM-tapering, and
shortwave forcing.  Convection and GM-tapering did not have runtime flags
until very recently.  Shortwave forcing is not yet fully implemented in c30,
but in working versions of the code, CPP flags are used.

>> So to control 32 packages you have to edit 32 header fiels?

No.  In CPP_OPTIONS.h, you would need 32

    #include "PKGX_OPTIONS.h"

as opposed to 32

    #define ALLOW_PKGX

If you want to further modify package options you would need to edit the
individual package header fields as is the case with present code structure.

If certain packages have no PKG_OPTIONS file, then a mix of #include and
#define commands could be used in CPP_OPTIONS.h

>> PS> When Chris added all the CPP flags, he immediately regretted it (see
>> comments in tag-index). We basically want to remove as much CPP flagging as
>> possible and reduce it to the bare minium number of flags to grossly shape
>> the code.

The reality is that for applications that push the computational envelope, CPP
options are very, very useful.  For most packages we use at JPL (e.g.,
K-FILTER, KPP, MIX, and GSGT) memory utilization is "always" an issue and
hence the need to turn things on and off using CPP options rather than runtime
flags.

>> There shouldn't be any KPP related code in the main code. It
>> should all be done by [optional] calls to kpp_*(). Isn't that the idea?

Totally agree.  That's the motivation for moving package checking to
individual packages.

Anyways, I am aware that you guys are trying to balance many competing factors
in a much larger and longer-term context than my own limited perspective.  I
am just offering feedback which you can adopt or ignore as you see fit.

Cheers, D.