[MITgcm-devel] mypackage_calc_rhs.F

[Jean-Michel Campin]

Hi Dimitris,

to answer the 2nd point:
> Regarding discussion below, I will leave as is until you
> have decided how you want to proceed.
> If the reason for carrying the spurious #ifdef ALLOW_MYPACKAGE
> is for local copy of code, then do we need to carry it in the main branch?

I realized my explanations might not have been very clear. 
To be more explicit, 3 possibilities:
1) mypackage_diagnostics_state.F version 1.1 (the one I checked in),
which is consistent regarding #ifdef ALLOW_MYPACKAGE, since both
the #include "MYPACKAGE.h" and the computations are within 
#ifdef ALLOW_MYPACKAGE / #endif
2) version 1.2 which always #include "MYPACKAGE.h", but ignore
the computations (within ifdef ALLOW_MYPACKAGE / #endif).
3) alternative version, also consistent, with both #ifdef ALLOW_MYPACKAGE 
removed, always #include "MYPACKAGE.h" and the routine computation part.

The reason I went for (1) is to allow more flexibility, as mentioned earlier:
> In practice, it (should) allows me to have a local copy of
> mypackage_diagnostics_state.F
> in my code dir (+MYPACKAGE_OPTIONS.h), and still be able to compile with
> or without mypackage in code/packages.conf
We could decide at some point to go for solution (3) instead of (1),
(but have other priorities right now), but don't feel like we
should stay with, what I consider to be, the less consistent solution (2),
especially because the cvs-check-in description does not reflect the real 
changes between version 1.1 and 1.2. 
Going to revert to 1.1 with few more comments.

Cheers,
Jean-Michel

On Sun, Aug 07, 2011 at 08:55:14PM -0700, Menemenlis, Dimitris (3248) wrote:
> Jean-Michel, regarding verification experiment for bbl,
> would it be OK to just turn on useBBL in one of the existing
> set-ups, e.g., the baseline or the seaice global_ocean.cs32x15.
> That way there is no additional test integrations needed.
> This would mean that I have to change output.txt or output.seaice.txt
> Let me know if OK to proceed as above or if you prefer that
> I add one more input directory and output file.
> 
> Regarding discussion below, I will leave as is until you
> have decided how you want to proceed.
> If the reason for carrying the spurious #ifdef ALLOW_MYPACKAGE
> is for local copy of code, then do we need to carry it in the main branch?
> 
> Cheers
> 
> Dimitris Menemenlis
> 
> On Aug 7, 2011, at 9:25 AM, Jean-Michel Campin wrote:
> 
> > I tend to prefer the way it was (with #ifdef ALLOW_MYPACKAGE around
> > #include "MYPACKAGE.h") since all this S/R is almost empty (every thing
> > within #ifdef ALLOW_MYPACKAGE) when ALLOW_MYPACKAGE is undef.
> > In practice, it (should) allows me to have a local copy of mypackage_diagnostics_state.F
> > in my code dir (+MYPACKAGE_OPTIONS.h), and still be able to compile with
> > or without mypackage in code/packages.conf 
> > And for a type of modular pkg like mypackage, might be something
> > we want to maintain. But it's more an open question.
> > And for this reason, I would not put back now the #ifdef ALLOW_MYPACKAGE
> > in mypackage_diagnostics_state.F, will see later on.
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel