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

Fri Mar 17 15:50:47 EDT 2017

Matt,

> I am really not sure where this comes from….

I dont know either but I am getting more and more convinced that we need more daily tests of the generic pkg/ecco (and pkg/ctrl) codes.

>  The responsible variables are : gsnm,gtnm,gunm,gvnm,wvel
This may suggest something to do with (1) pkg/mom_common, flux form, or vecinv or (2) maybe free surface options.

> You can’t reproduce this with ECCO_v4_r2?

No, I do not get this recomputation in ECCO_v4_r2.

> With those commented out I have no packages that are not also in MITgcm_contrib/gael/verification/ECCO_v4_r2/code

Maybe install either ECCO_v4_r2 (as explained in http://wwwcvs.mitgcm.org/viewvc/MITgcm/MITgcm_contrib/gael/verification/eccov4.pdf?revision=1.32&view=co) or global_oce_cs32 (as explained in http://wwwcvs.mitgcm.org/viewvc/MITgcm/MITgcm_contrib/verification_other/global_oce_cs32/README?view=co which is a lightweight version of ECCO_v4_r2 used for daily test purposes). Then copy and paste compile options between this one and your setup until you break or fix one of the two.

Hope this helps,
Gael

On Mar 16, 2017, at 9: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> 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> 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> 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> 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> 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> 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> wrote:
>>>>>>>> 
>>>>>>>> Hi Matt, what verification experiment shows this recomputation? Gael
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mar 1, 2017, at 2:48 PM, Matthew Mazloff <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
>>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20170317/a1fee142/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1843 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20170317/a1fee142/attachment-0001.p7s>