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

mitgcm-support at dev.mitgcm.org mitgcm-support at dev.mitgcm.org
Wed Jul 9 15:51:59 EDT 2003


Hi Dimitris,

 Will call you Thursday. Not sure what Alistair thinks
but it soumds about OK to me. Still don't quite understand
the CPP_OPTIONS.h bit. Will think about it - talk to you
Thursday.

 If you can point to the problems with SW forcing I will
take a look.

Chris

"Dimitris Menemenlis
> 
> >> What are the inconsistencies?
> 
> I don't have a complete list yet, but they include treatment of
> shortwave forcing and package initialization and checking.
> 
> The general idea is that package maintainers should be able to
> modify packages with minimum modifications to baseline code and
> hence without having to molest you and Alistair on a continuous
> basis. What you suggest is better than what is actually there
> right now but still falls short from what I believe is needed.
> 
> 1. My preference would be for CPP_OPTIONS.h and its dependents
> to be visible to all model subroutines.  For example when using
> KPP I want to turn off convection and turn on short-wave forcing.
> The way this would be handled right now is by issuing warnings
> and aborting at runtime in package_check, which seems a bit
> wasteful.  So instead of
> 
>     CPP_OPTIONS.h
>     #define ALLOW_PKG1
>     #define ALLOW_PKG2
>     ...
>     #define CPP_OPTION1
>     #define CPP_OPTION2
>     ...
> 
> I suggest we use
> 
>     CPP_OPTIONS.h
>     #define CPP_OPTION1
>     #define CPP_OPTION2
>     ...
>     #include "PKG1_OPTIONS.h"
>     #include "PKG2_OPTIONS.h"
> 
> It's up to package maintainers to make sure their options do not
> interfere with baseline code and with other packages.  For example,
> package option files couls be as simple as:
> 
>     PKG1_OPTIONS.h
>     #define ALLOW_PKG1
> 
> But they could also do things like:
> 
>     PKGX_OPTIONS.h
>     #define ALLOW_PKGX
>     #ifdef ALLOW_PKGX
>     #undef CPP_OPTIONX
>     ...
>     #endif
> 
> 2. PACKAGE_CHECK and PACKAGE_INIT
>    Note that file names and subroutine names are spelled differently,
>    and that right now these routines are very different from what you
>    describe in your message.
> 
>    As you suggest it's best to let each package check for
>    inconsistencies on its own.  Otherwise you or Alistair will
>    have to intervene every time someone tries to change something in
>    the package.  Again the idea is to transfer responsibility from
>    you and Alistair to individual package maintainers.  I much
>    prefer your second option which is to altogether get rid of
>    PACKAGE_CHECK.
> 
>    The only purpose of PACKAGE_INIT and data.pkg right now is to set
>    or unset use_PKGX.  Both KPP_INIT and GMREDI_INIT appear in
>    initialise_varia.F.  Again I prefer your option #2, that is, call
>    PKGX_INIT from the baseline code and let the  package maintainer
>    decide whether he needs (or wants) to define a use_pkgx flag.
> 
> To summarize I vote for minimum restrictions and minimum interference with
> baseline code, where practical, so that I have to bug you and Alistair as
> little as possible.
> 
> Dimitris




More information about the MITgcm-support mailing list