[MITgcm-devel] mypackage_calc_rhs.F

[Jean-Michel Campin]

Hi Dimitris,

I am fine with turning on useBBL in the baseline global_ocean.cs32x15
(preferably not in global_ocean.cs32x15.seaice, which has enough
of specific thing to test). But before doing this, let me
figure out why the lab_sea AD test is taking so much time today
( > 160 longer than yesterday).

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