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

[mitgcm-support at dev.mitgcm.org]

"Dimitris Menemenlis
> 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

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?

> 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

Again, can you explain - show me what you mean?

> more and more robust until ultimately they are all reduced to
> 
>     PKGX_OPTIONS.h
>     #define ALLOW_PKGX

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

> which would then be exactly equivalent to what you advocate.

I didn't say anything along these lines. I prefer centralized
selection of packages and private determination of details (parameters).

> For code efficiency and size, it does not make sense to control some packages
> by runtime parameters.

Agreed, which is when you use CPP to "optimize". But the CPP options
should not be the only way to do it.

>                        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.

No problem with me. I imagined that "data" would be phased out and to save
incompatibility later, data.pkg would stay. As to ignoring control files...

Alistair.
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. 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?