[MITgcm-devel] problem with argument list of adthe_main_loop

Tue Apr 27 10:17:47 EDT 2010

Hi Martin,

turns out, quick solution is to use more, rather than less:
Turn on down_slope package,
for which case all appropriate extra stores are already in place,
and you don't have to change anything.

Down slope doesn't do much good (sorry J.-M.), at least with default  
params.,
but doesn't do much bad either (I think it just doesn't do much).

The one extra recomp. from down_slope you can ignore.
The recomp. from advect.F you can ignore as well.
There had actually been a bug: since advect is called multiple times,
stores were overwritten (Gael caught that one).

-p.

On Apr 27, 2010, at 9:10 AM, Patrick Heimbach wrote:

>
> Will take a look
> (maybe not before tonight).
> -p.
>
> On Apr 27, 2010, at 9:06 AM, Martin Losch wrote:
>
>> Hi Patrick,
>>
>> thanks, I think Takasumi followed "cost_atlantic_heat" (at least  
>> the code looks like that).
>> Based on his work, I have now (after a few tweaks) a 5 timestep  
>> adjoint simulation that makes sense, however with the seaice  
>> package disabled.
>> When I turn on the seaice package, many recomputations appear (and  
>> I don't mean the "benign" ones related to dsigmadr, tsurfloc, alb,  
>> tices, fld(in advect.F), cvv, cuu, etc), see for example:  
>> ross.mit.edu:/raid1/mlosch/MITgcm/cs32/build_ad/taf_ad.log
>> I am not sure, but I think the recomputations are found around  
>> line 101510 in ad_taf_output.f where within do ilev_1, another "do  
>> ilev_18" starts. The resulting run takes about 2-3 times longer  
>> than with out seaice. Is this correct? Do I have to live with that?
>>
>> Martin
>>
>>
>> On Apr 27, 2010, at 2:03 PM, Patrick Heimbach wrote:
>>
>>>
>>> Hi Martin,
>>>
>>> very quickly, it should work both ways,
>>> but "easier" seems without ECCO package (less "baggage").
>>> I've been running various sensitivities using a setup
>>> with seaice using ECCO-setup, but without ECCO package.
>>>
>>> As a starting point, if you want to try non-ECCO route,
>>> take a look at what's in
>>> cost_accumulate_mean.F and cost_atlantic_heat.F
>>> The latter is a bit rudimentary and out of date,
>>> but contains several cost functions.
>>> You'll need to adapt to general grid geometry.
>>>
>>> -p.
>>>
>>> On Apr 27, 2010, at 2:41 AM, Martin Losch wrote:
>>>
>>>> Hi Patrick,
>>>>
>>>>
>>>> sorry for the inaccurate description of the problem. I was just  
>>>> looking for a general explanation/direction. Both you have  
>>>> provided, thanks.
>>>>
>>>>
>>>> I found that with ecco, you need at least one "time-dependent"  
>>>> costfunction contribution (e.g. ALLOW_THETA_COST_CONTRIBUTION)  
>>>> for the "mytime" to appear in the argument list of  
>>>> adthe_main_loop. This corresponds to your description.
>>>>
>>>>
>>>> In the end I/we want to use the ecco package in a "standard"  
>>>> form so that this problem will not affect use, but right now I  
>>>> want to compute the sensitivity to meridional overturning in a  
>>>> cs32 configuration with seaice. We (Takasumi and I) tried with  
>>>> and without the ecco package.
>>>> 1. without ecco: I put my cost function computations into  
>>>> cost_test (just as in bottom_ctrl_5x5) and get many  
>>>> recomputations, most likely due to the seaice (at least they all  
>>>> go away when I turn off seaice). Since I did not have time then  
>>>> (and do not have it now either, unfortunately) to dig into that,  
>>>> I recommended to Takasumi to try this:
>>>> 2. with the ecco package, I put my cost function into  
>>>> cost_usercost_all.F and I do not get recomputations (however so  
>>>> far I also did not get a cost contributions from cost_usercost,  
>>>> I have just started with that, so give me some more time), but  
>>>> we have this "mytime, mythid" problem. I can now circumvent that  
>>>> by having fake theta-cost functions (with mult_theta=0.)
>>>>
>>>>
>>>> So my question is, according to your experience, which route  
>>>> will be faster to the goal (sensitivity of the overturning with  
>>>> respect to surface forcing), the ecco or the non-ecco route. I  
>>>> have the feeling the non-ecco route, but only if you point me to  
>>>> where I have insert store directives to fix the recompuations.  
>>>> If you find the time (today), I'd love to show you my  
>>>> configuration.
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Patrick Heimbach <heimbach at MIT.EDU>
>>>> Date: Tuesday, April 27, 2010 5:07
>>>> Subject: Re: [MITgcm-devel] problem with argument list of  
>>>> adthe_main_loop
>>>> To: MITgcm-devel at mitgcm.org
>>>>
>>>>>
>>>>> Hi Martin,
>>>>>
>>>>> I haven't looked into this in a long time.
>>>>> As you see, the "broad" behavior is that
>>>>> mycurrenttime is kept for ECCO, but not otherwise.
>>>>>
>>>>> If I remember correctly, I tried a number of ways to "recompute"
>>>>> mycurrenttimewithin the_main_loop and make it "self-sufficient"
>>>>> (e.g. use starttime), but didn't help much.
>>>>> I think I also tried the other way round, i.e. "force" TAF to
>>>>> keep mycurrenttime always,
>>>>> but didn't help much either.
>>>>> My hunch is it has to do with the use (or non-use) of the
>>>>> cost_averages... routines.
>>>>>
>>>>> But would have to see your setup in detail ;)
>>>>> in particular, what's the difference between the two cases.
>>>>>
>>>>> I had not pursued this further, since it seems stable for most
>>>>> applications,and can be easily changed in case of unexpected  
>>>>> behavior.
>>>>>
>>>>> Cheers
>>>>> -p.
>>>>>
>>>>> On Apr 26, 2010, at 9:08 AM, Martin Losch wrote:
>>>>>
>>>>>> Hi there (Patrick in particular),
>>>>>>
>>>>>> I found this in the archives (the search functions seems to
>>>>> work better):
>>>>>> http://forge.csail.mit.edu/pipermail/mitgcm-devel/2008-
>>>>> June/003425.html>and I seem to have a similar problem in a
>>>>> particular configuration:
>>>>>> in ad_taf_output.f I find
>>>>>> subroutine adthe_main_loop(mythid)
>>>>>> but it's called as adthe_main_loop(mycurrenttime, mythid) from
>>>>> the_model_main.F>
>>>>>> I have other configurations where taf properly produces
>>>>> "subroutine adthe_main_loop(mytime,mythid)", but I cannot see
>>>>> why. Both configurations use the ecco package (so ALLOW_ECCO is
>>>>> defined, that's why the_model_main requires mytime and mythid)
>>>>> and pretty similar ECCO_CPPOPTIONS.h.
>>>>>>
>>>>>> Can you point me to the critical parameters that let taf
>>>>> produce the argument list with (mytime, mythid)? Is the type of
>>>>> cost function?
>>>>>>
>>>>>> 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-1518 | 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
>>>>
>>>> Martin Losch
>>>> Alfred Wegener Institute
>>>> Postfach 120161, 27515 Bremerhaven, Germany;
>>>> Tel./Fax: ++49(0471)4831-1872/1797
>>>>
>>>>
>>>> _______________________________________________
>>>> 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-1518 | 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
>
> ---
> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>
>

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach