[Mitgcm-support] Re: CAUTION !!!

[mitgcm-support at dev.mitgcm.org]

Currently, there is no model routine that #includes a header file
from a package. So the answer is all header files are private but
maybe we'd need a public one for some operations (can't
think of one of hand).

Right now, if use_KPPmixing is set and ALLOW_KPP isn't then
the model does report an error and stops.

If you don't want "use_KPPmixing" to be public
then I'd rather put the "if (use_KPPmixing)" inside
each kpp_* routine rather than add yet more lines of
code to every package and the model. A public exported
header file for each package means an #ifdef #include #endif
for every package in routines like dynamics() and calc_gt().


A.

Chris Hill wrote:

> Hi Honey,
>
>   Here's what I would do. use_KPPPmixing is to
> be owned by the package - but in a public
> exported header file.
>
> Its initial value is set by a special package
> routine
>  packages_boot, init whatever.
>  which is always called and reads
> data.pkg.
>
>  However, use_KPPPmixing uses are private to
> the package and it is the responsibility
> of the package to make it do the right
> thing i.e. return straight away.
>
>  For checking package dependencies there are
> two options
>  1. have kpp_init check that useXXXX is set
>     for everyone it needs. That implies the
>     useXXXX are publically exported from each
>     package.
>  2. have packages_init hold the rules.
>
>  1. is the more "professional" way of doing it
> according to the software engineering rule book.
>
>  What happens if I set use_KPPmixing in data.pkg
> but have #undef KPP? How is that trapped?
>
>  Do we have a public and private header file
> concept for packages?
>
>  Do packages need versions? Aren't depndencies
>  likely to be
>   if ( useKppMixing .and. kppVersion .gt. 13 ) OK
>
> XXXXXXXXXXXXXXXXXXXXXX