[MITgcm-devel] major recomputations with move of ecco_phys call

[Matthew Mazloff]

ps> last thing I should note:  those stores are in the main_loop, e.g.:

CADJ STORE gtnm = tapelev2, key = ilev_2
CADJ STORE gsnm = tapelev2, key = ilev_2
CADJ STORE gunm = tapelev2, key = ilev_2
CADJ STORE gvnm = tapelev2, key = ilev_2

But its still giving recomps

-Matt



> On Mar 16, 2017, at 6:13 PM, Matthew Mazloff <mmazloff at ucsd.edu> wrote:
> 
> ps> I should add though, even when I comment out
> ptracers, gchem, bling, obcs
> in packages.conf
> I still get this, so its not specifically BLING
> 
> With those commented out I have no packages that are not also in 
> MITgcm_contrib/gael/verification/ECCO_v4_r2/code
> 
> I have looked at differences in the *.h files in my setup vs ECCO_v4_r2 but nothing seems significant.
> 
> The TAF comment is:
> 
> TAF RECOMPUTATION LOOP WARNING DOLOOP_STMT ad_input_code.f:400479 in the_main_loop
>  extensive recomputations are required.
>  The responsible variables are : gsnm,gtnm,gunm,gvnm,wvel
> 
> You can’t reproduce this with ECCO_v4_r2?
> 
> I am really not sure where this comes from….
> 
> Matt
> 
> 
>> On Mar 16, 2017, at 3:32 PM, Matthew Mazloff <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
>> 
>> Hi Gael
>> 
>> Thanks for getting back to me on this. I am not sure what it is about my setup that causes this. I will let you know if I can determine it. I am trying to stay very close to ECCOv4 setup, although I do have BLING… 
>> 
>> And I’m obviously very curious if An or anyone else has experienced this!
>> 
>> I’ll let you know if I have an update
>> 
>> Matt
>> 
>>  
>>> On Mar 16, 2017, at 2:45 PM, gael forget <gforget at mit.edu <mailto:gforget at mit.edu>> wrote:
>>> 
>>> Hi Matt,
>>> 
>>> thanks for following up on this and sorry for the delayed response. 
>>> 
>>> I can see how an on/off switch based on run-time parameters would make sense to avoid calculating 
>>> trVol, trHeat, and trSalt if they are never used but (1) I would leave this up to An who, unlike me, may 
>>> have a working benchmark for these codes and (2) this probably would not help you anyway. 
>>> 
>>> On the other hand, I am definitely not in favor of re-introducing CPP options in the main trunk. Also, 
>>> I still do not see the major recomputation which you are referring to. If it can easily be reproduced 
>>> using global_oce_biogeo_bling or another verification experiment then I could take a quick look.
>>> 
>>> Cheers,
>>> Gael
>>> 
>>> On Mar 3, 2017, at 7:16 PM, Matthew Mazloff <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
>>> 
>>>> Hi Gael
>>>> 
>>>> I can make the major recomputations go away by commenting out lines 146 to 227 in ecco_phys.F. These lines are where the transport of volume, heat, and salt are calculated:
>>>>  trVolW, trVolS, trHeatW, trHeatS, trSaltW, trSaltS
>>>> 
>>>> I don’t need that code so I will just hide it in a CPP option for now instead of chasing down where stores need to be added. 
>>>> 
>>>> However, can we hide that code behind some CPP option in the main code? I see they used to be within ALLOW_GENCOST_TRANSPORT but that flag was removed as revision 1.8. Can we put that back in? It seems inefficient to calculate those terms if not being used in a cost function
>>>> 
>>>> Thanks!
>>>> Matt
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Mar 2, 2017, at 12:09 PM, Matt <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
>>>>> 
>>>>> Ok, maybe it's just my setup. I'll figure out what's causing it and let you know if relevant.
>>>>> 
>>>>> Thanks!
>>>>> Matt
>>>>> 
>>>>> 
>>>>> On Mar 2, 2017, at 11:01 AM, gael forget <gforget at mit.edu <mailto:gforget at mit.edu>> wrote:
>>>>> 
>>>>>> I have not noticed any but please let me know if I overlooked one. Cheers, Gael
>>>>>> 
>>>>>> On Mar 2, 2017, at 1:21 PM, Matthew Mazloff <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
>>>>>> 
>>>>>>> Hi Gael
>>>>>>> 
>>>>>>> I haven’t checked the verification experiments. Sorry for the miscommunication -- I was asking if you had. Do any of the testers or your setup show major recomputations? 
>>>>>>> 
>>>>>>> Matt
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mar 2, 2017, at 10:14 AM, gael forget <gforget at mit.edu <mailto:gforget at mit.edu>> wrote:
>>>>>>>> 
>>>>>>>> Hi Matt, what verification experiment shows this recomputation? Gael
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mar 1, 2017, at 2:48 PM, Matthew Mazloff <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
>>>>>>>> 
>>>>>>>>> Hi Gael
>>>>>>>>> 
>>>>>>>>> I just updated to the latest code from checkpoint66c and am getting major recomputations from this modification:
>>>>>>>>> 
>>>>>>>>> "move call to ecco_phys to end of time step; this may induce minor cost function changes by shifting time averages by one time step for some variables; this revision resulted in changed adjoint results in MITgcm_contrib/verification_other/global_oce_cs32”
>>>>>>>>> 
>>>>>>>>> The recomputations go away when I move the call back from 
>>>>>>>>> 	forward_step.F
>>>>>>>>> to
>>>>>>>>> 	do_oceanic_phys.F
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Can you please check if you also get major recomputations for the test runs with this modification or if this is something specific to my setup. 
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Matt
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> MITgcm-devel mailing list
>>>>>>>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> MITgcm-devel mailing list
>>>>>>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> MITgcm-devel mailing list
>>>>>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> MITgcm-devel mailing list
>>>>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>>>> 
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel <http://mitgcm.org/mailman/listinfo/mitgcm-devel>
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20170316/3585c967/attachment-0001.htm>