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

[mitgcm-support at dev.mitgcm.org]

Hi Dimitri,

 Don't worry Alistair and I do read most things under mitgcm.org and under the
various ecco sites. Thats one big reason we decided to
get involved in sorting this out :-)....
Didn't know about the document Patrick had written as it
wasn't at any of the main sites, thanks
for bringing it to our attention. He put it there in early
May which was before he had really figured out what a mess
Christian and Ralf had left him.

 I can only see a few minor inconsistencies and a few new features in what 
we have outlined. These are as follows:

 we shouldn't require $(PACKAGE)_CPPOPTIONS.h to be included 
 in CPP_OPTIONS.h. That is a mistake. We are not saying you can't
 do it though - just that if you don't need to then don't do it.

 the keyword ALLOW_ is already widely used in the code. "use" 
 is already used for a runtime flags in the code - so something 
 needs fixing. Don't mind too much which way it goes but since
 the de facto convention is ALLOW_ to include the code and
 use$(Package) it might make sense to use that.

  1. we have added a boot sequence that precedes pacakge_init.F.
     This sequence is 
      PACKAGES_READ_PARMS()
       CALL $(PACKAGE1)_READ_PARMS
       CALL $(PACKAGE1)_READ_PARMS
          :

      PACKAGES_CHECK()
       CALL $(PACKAGE1)_CHECK
       CALL $(PACKAGE1)_CHECK
          :

  2. $(PACKAGE)_READ_PARMS is supposed to do one thing and
     only one thing. This is to read the data.$(package). It is not
     the same as $(PACKAGE)_INITFIXED which might for example
     read data in from a binary file, check valid parameter values or
     report package setup. The only thing $(PACKAGE)_READ_PARMS
     does is gets things to a state where a basic PACKAGES_CHECK()
     validation can be performed.

  3. The separation of use$(Package) and $(package)PackageIsOn and
     the support of a global data.packages could be important and
     we think it is worth trying. Keeping use$(Package) out of the
     packages is a mechanism that allows the possibility of binary packages 
     which do not need to be rebuilt every time a new package is added.

 Note - it is vital that we all agree on what to do
        here and that what is defined can actually work. 
        So constructive input and criticism is very welcome. Patrick and I see 
        eye to eye on these things and are both determined to produce something 
        that is a product we can all be proud of. The only reason Patrick wasn't
        in the loop on the e-mail yesterday is because he is 
        climbing in Bolivia and he didn't take his palm pilot and I wanted
        to get some feedback ASAP. Patrick is back on Wed. 
        this week and he and I will talk then. Once the four of us 
        (me, Alistair, Patrick and you) are happy we will put the document 
        out for wider comment from everyone involved (Ralf, Arne etc..). It
        is not the plan to simply write another random document whose status
        is unclear. Once this one is done I would like to do a similar thing 
        with the "coding guidelines" document - what fun!!


 Aghhhh - the campers are up!!!!


see you,

Chris