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

[Matthew Mazloff]

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 <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
> 
> _______________________________________________
> 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/6b659e8a/attachment-0001.htm>