[MITgcm-devel] problem with argument list of adthe_main_loop

Tue Apr 27 10:31:02 EDT 2010

Hi Patrick,

thanks, as usual you are faster than me. I had also found the downslope trick, just not as quickly as you. Also, I found this small problem:
comlev1_multdim is not defined in model/src/the_main_loop.F, copied from pkg/ecco/the_main_loop, gets rid of one recomputation warning (tices). 

Martin

On Apr 27, 2010, at 4:17 PM, Patrick Heimbach wrote:

> 
> 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
> 
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel