[MITgcm-devel] autodiff_store/restore/ALLOW_ECCO_EVOLUTION

Jean-Michel Campin jmc at ocean.mit.edu
Fri Mar 7 10:58:03 EST 2014


Hi Martin,

I think that with some work, we should be able to put all the 
CPP options from ECCO_CPPOPTIONS.h in their associated pkg
option files (AUTODIFF_OPTIONS.h COST_OPTIONS.h CTRL_OPTIONS.h
ECCO_OPTIONS.h and EXF_OPTIONS.h). This was the purpose of
adding an option file "ECCO_OPTIONS.h" (in Aug 2012) to make a clear 
distinction between pkg/ecco option file and the "special" multi-pkg
option file ECCO_CPPOPTIONS.h

In the mean time, I feel like it could become confusing to 
do half the work, i.e., to just move pkg/exf options
in EXF_OPTIONS.h but to keep ECCO_CPPOPTIONS.h for all others pkg
(autodiff, cost, ctrl, ecco) options:

1) it introduce a 3rd way a specifying CPP options that
 is in contradiction with the current ECCO_CPPOPTIONS.h documentation.
 For instance, in each ECCO_CPPOPTIONS.h we have these comments at the top:

C-- Collect here, in a single option-file, options to control which optional
C   features to compile in packages AUTODIFF, COST, CTRL, ECCO, CAL and EXF.
C   If used, this option-file needs to be directly included in CPP_OPTIONS.h
C   Although this method, inherited from ECCO setup, has been traditionally
C   used for all adjoint built, work is in progess to allow to use the
C   standard metod (each of the above pkg get its own options from its
C   specific option-file) also for adjoint built.

but this would need to be changed (in some places ? but not every-where ?)

2) when we multiply the number of different ways to make these setting,
 it makes more complicated to do the right check/stop.
 This is a more general problem (in MITgcm development) regarding user
 setting changes (going through multiple little changes which all 
 affect user settings instead of a clear, 1 step, update from 
 old setting to new one).

3) a cleaner way to introduce this new method (the 3rd way) would be to 
use a different file name rather than to change the meaning of
the file ECCO_CPPOPTIONS.h 

Cheers,
Jean-Michel

On Fri, Mar 07, 2014 at 03:24:50PM +0100, Martin Losch wrote:
> Hi again,
> 
> I don’t know about the utility of ALLOW_ECCO_EVOLTION, but I think I solved my problem, in case anyone is interested:
> 
> I prefer that have the cpp-flags for the exf-pkg in the EXF_OPTIONS.h file. This somehow clashes with the convention that for adjoint models these cpp-flags should now be in ECCO_CPPOPTIONS.h. This convention, which I’d like to challenge (again), has been cemented a little more by these lines 
> #ifdef ECCO_CPPOPTIONS_H
> dont do anythin
> #else
> here are the exf flags
> #endif
> that I found in my EXF_OPTIONS.h (which I grabbed from MITgcm_contrib/arctic/cs_36km/code, but it’s also in pkg/exf/EXF_OPTIONS.h).
> With this if-construct, EXF_OPTIONS.h are never loaded after ECCO_CPPOPTIONS.h has been loaded. In this sense the 
> #ifdef ALLOW_ECCO_EVOLUTION
> #ifdef ALLOW_EXF
> #include “EXF_OPTIONS.h”
> #endif
> #endif
> has no effect, because ALLOW_ECCO_EVOLUTION is typically defined in ECCO_CPPOPTIONS.h
> 
> My solution is to remove the if statement from the EXF_OPTIONS.h or should I rather remove ECCO_CPPOPTIONS.h and distribute the flags in there to AUTODIFF_OPTIONS.h/CTRL_OPTIONS.h/COST_OPTIONS.h/EXF_OPTIONS.h
> What’s the preferred method now?
> 
> Martin
> 
> On Mar 5, 2014, at 12:52 AM, Patrick Heimbach <heimbach at mit.edu> wrote:
> 
> > Hi Martin,
> > 
> > I can take a look after Thursday (currently on travel).
> > The flags seem a little messed up.
> > 
> > p.
> > 
> > On Mar 4, 2014, at 12:29 PM, Martin Losch <Martin.Losch at awi.de> wrote:
> > 
> >> Hi there,
> >> 
> >> I have a setup for which I do not want to use the ecco package, but seaice, exf, etc.
> >> 
> >> I think that autodiff_store/restore do not compile without ECCO, at least not in my case because the
> >> #ifdef ALLOW_ECCO_EVOLUTION 
> >> prevents loading the EXF_OPTIONS.h, that in turn prevent defining ALLOW_RUNOFF and the variable runoff is not defined (line 548).
> >> 
> >> How do I fix that so that it doesn’t break things for ECCO or anyone else? Remove the #ifdef ALLOW_ECCO_EVOLUTION? so that EXF_OPTIONS.h are always included as long as ALLOW_EXF is defined?
> >> 
> >> Martin
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> > 
> > ---
> > Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
> > MIT | EAPS 54-1420 | 77 Massachusetts Ave | Cambridge MA 02139 USA
> > FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel



More information about the MITgcm-devel mailing list