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

[mitgcm-support at dev.mitgcm.org]

Hi Dimitris,

 Certainly we can change these but I have some comments..

 o General comments

 Alistair we need to get your thoughts too as this is
 important to get a clear agreement on. 
 D. I will be down at WHOI Thursday so Alistair
 and I will also call you to make sure we all know what
 structure we are adopting.

 What are the inconsistencies?

 o Comments on 1., 2., 3.,

 1. By and large packages will be self-contained and ultimately
    CPP_OPTIONS.h will contain almost nothing except
    #define ALLOW_PKGX1
    #define ALLOW_PKGX2
    etc.. The rest of the package specific options will be
    in the header files for the package. If the package wants
    to "import" other package headers because of dependencies
    thats fine. However, having everything in CPP_OPTIONS
    seems like it would make some things globally visible that 
    really don't need to be. So I imagined a structure which looks
    like
    CPP_OPTIONS.h
    #define ALLOW_PKGX1
    #define ALLOW_PKGX2
      :
      :

    PKGX1_OPTIONS.h
    #define PKGX1_SET_OPTION1
    #undef  PKGX1_SET_OPTION2
    #define PKGX1_SET_OPTION3

 2. S/R PACKAGES_CHECK should just read
    S/R PACKAGE_CHECK
    #include "CPP_OPTIONS.h"

    #ifdef ALLOW_PKGX1
      CALL PKGX1_PACKAGES_CHECK( retCode )
    #endif  

    #ifdef ALLOW_PKGX2
      CALL PKGX2_PACKAGES_CHECK( retCode )
    #endif  

    etc....

    or go altogther with everything checked in S/R PACAKGES_INIT which
    would read

    S/R PACKAGES_INIT
    #include "CPP_OPTIONS.h"

    #ifdef ALLOW_PKGX1
      CALL PKGX1_INIT( retCode )
    #endif  

    #ifdef ALLOW_PKGX2
      CALL PKGX2_INIT( retCode )
    #endif  

    etc....

    3. Can't see how we can get rid of pacakages_init().
       But it should read like 2. above. 
       I would vote for keeping data.pkg but using a
       better piece of parsing code than NAMELIST. There
       is a library called I90 that we could use for now.
       Alternatively we could have use_pkgx1 = ....
       in data.pkgx1. Don't want the test of the presence of
       the file to be the switch though. Its better to
       have a variable in data.pkgx1.

    4. The packages mechanism does not have to be bullet-proof. It is 
       a solution that will persist for some time but not forever.
       Down the road it looks we will get some funding to do something
       more flexible. The most important thing at this stage is to get
       code being developed in a style that is consistent with
       existing under some "packaging" mechanism. The packaging 
       mechaism itself does not have to 100% perfect, just good
       enough for people to start thinking about it the right way.

    What are your thoughts? What will/won't work if we do things
    as I described?

Chris

"Dimitris Menemenlis
> 
> Chris and Alistair, I am in the process of comparing c30,
> ecco_c30_ralf, and the jpl_mitgcmuv.  As far as KPP package
> is concerned, the codes have already started to diverge in
> incompatible ways.  I am wondering whether you would consider
> modifying packaging slightly to give more control to package
> maintainers and minimize interactions of packages with main code.
> 
> I suggest following modifications:
>  
> 1) Package code is included by appending
>       #include "PKGX_OPTIONS.h"
>    at end of CPP_OPTIONS.h.  File PKGX_OPTIONS.h will usually
>    contain flag ALLOW_PKGX and may modify CPP_OPTIONS.h as
>    required.
> 
> 2) Get rid of packages_check.F.  Each package is responsible
>    for taking care of its own checks during initialization,
>    including CPP flags and presence or absence of other packages.
> 
> 3) Get rid of data.pkg and packages_init.F.  Each package is
>    responsible for setting or unsetting its own use_pkgx flag
>    if desired.  (A convenient way to do that is for packages
>    to check for presence or absence of file data.pkgx)
> 
> If you agree with these changes, I can take care of implementing
> in the three codes and sending you updates.
> 
> Either way, let me know as soon as possible so I can proceed,
> Dimitris