[MITgcm-devel] main_do_loop.F

Gael Forget gforget at MIT.EDU
Mon Mar 4 14:07:31 EST 2013


Hi Patrick,

sounds great. I have been a proponent of this 
approach for a while, so I certainly wont object now.
Last time I checked (in the fall) everything was 
in place to proceed with 1-2-3. At that time 
I also checked the untested divided adjoint, 
which may be worth double checking now.

As far as the ecco version4 verification experiment,
the local copies of the_main_loop.F & forward_step.F
were just identical copies of the model/src versions 
(last synced up on Feb 5th). They were only necessary
to override the pkg/ecco versions, which themselves 
were overriding the model/src versions (lol). So as
as soon as you remove ecco/the_main_loop.F & 
forward_step.F, there should be no need for such 
local copies in my verification experiment.

Cheers,
Gael

On Mar 1, 2013, at 4:09 PM, Patrick Heimbach wrote:

> 
> Hi Gael, Jean-Michel,
> 
> I took a look and think I have the change to the_main_loop.F (started Feb 20),
> which now calls main_do_loop sorted out for the ECCO setups as well
> (e.g. global_oce_llc90, global_oce_cs32, etc).
> 
> At the same time of checking this code in, some cleanup might be very useful
> and desirable since these modifs are related (and will simplify things). 
> Mainly what I suggest is:
> 
> 1. remove (undesired) versions of the_main_loop.F, forward_step.F in pkg/ecco/
> 
> 2. remove following split in the_model_main.F since it's no longer needed.
> #   ifdef ALLOW_ECCO
>      CALL ADTHE_MAIN_LOOP ( myTime, myThid )
> #   else
>      CALL ADTHE_MAIN_LOOP ( myThid )
> #   endif
> 
> This also allows removal of special the_model_main.F files
> in several code_ad/ directories.
> 
> 3. Not sure yet, but perhaps we can try to make the flag 
> #define ALLOW_ECCO_EVOLUTION
> default (not sure if it makes sense, will see).
> 
> If we do that, we should make a checkpoint tag afterwards since it's an 
> important change regarding backward compatibility of configurations
> (it should be clear that people don't mix before/after configurations).
> 
> Any comments/objections?
> 
> Cheers
> -Patrick
> 
> ---
> 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




More information about the MITgcm-devel mailing list