[MITgcm-devel] bling adjoint example

Sat Sep 17 15:24:37 EDT 2016

Hi Matt,

gT and gS were removed from common block dynvars_r in August 2015.
The mismatch in addynvars_r appears to be benign,
otherwise we would have noticed in testreport.
Probably all the following adjoint fields might be zero at that point,
and so no impact (it seems, I haven't verified). 
I'll change the file in pkg/autodiff.

Cheers
-Patrick

> On Sep 17, 2016, at 1:38 PM, Matthew Mazloff <mmazloff at ucsd.edu> wrote:
> 
> Hi Patrick
> 
> Thanks!!
> 
> I did check in that store (as you probably saw).
> 
> Regarding the addummy_in_stepping.F problem — sorry — false alarm!  It is now gone and must have been related to other code that I have since removed. Or possibly I had issues with CPP options that have since changed. Anyway, its not needed…no bug :o)
> 
> 
> So that adcommon does seem serious.  Is /MITgcm_contrib/verification_other/global_oce_biogeo_bling/code_ad/ the only setup where you see this? If it is I will check in a correct adcommon for this setup. But if not, are you planning on trying to correct the pkg/autodiff/adcommon.h? How to proceed?
> 
> 
> Thanks!
> Matt
> 
> 
> 
>> On Sep 16, 2016, at 8:26 PM, Patrick Heimbach <heimbach at MIT.EDU> wrote:
>> 
>> Hi Matt,
>> 
>> please see inlined below.
>> 
>>> On Sep 14, 2016, at 4:38 PM, Matthew Mazloff <mmazloff at ucsd.edu> wrote:
>>> 
>>> Hello
>>> 
>>> I checked in a bling adjoint example. 
>>> http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/verification_other/global_oce_biogeo_bling/code_ad/
>>> 
>>> Note two files in code_ad that I would rather not have there:
>>> addummy_in_stepping.F
>>> external_forcing_surf.F
>>> 
>>> In addummy_in_stepping.F
>>> I had to comment out:
>>> 152	cmm         CALL ADEXCH_UV_XY_RS( adFu, adFv, .TRUE., myThid )
>>> 153	cmm         CALL ADEXCH_XY_RS( adQnet, myThid )
>>> 154	cmm         CALL ADEXCH_XY_RS( adEmPmR, myThid )
>>> is this a bug?
>> 
>> Not sure what's going on since this piece of code has been around for years, 
>> but you may have stumbled over a wider problem
>> (or it may be too late in the day and I am writing nonsense?):
>> 
>> Looking at the common block for addynvars_r that TAF generates
>> (in file ad_taf_output.f), we get:
>> 
>>     common /addynvars_r/ etan_ad, uvel_ad, vvel_ad, wvel_ad, theta_ad,
>>    $ salt_ad, gu_ad, gv_ad, gunm1_ad, gvnm1_ad, gtnm1_ad, gsnm1_ad
>> 
>> But looking at the common block we provide 
>> (in pkg/autodiff/adcommon.h), it is:
>>     common /addynvars_r/
>>    &                     adetan,
>>    &                     aduvel, advvel, adwvel,
>>    &                     adtheta, adsalt,
>>    &                     adgu, adgv, adgt, adgs,
>> #ifdef ALLOW_ADAMSBASHFORTH_3
>>    &                     adgunm, adgvnm, adgtnm, adgsnm
>> #else
>>    &                     adgunm1, adgvnm1, adgtnm1, adgsnm1
>> #endif
>> 
>> Comparing the two, there are two entries missing in the
>> new code that TAF generates: adgt, adgs, 
>> (or rather, gt_ad, gs_ad ,in TAF's newer notation, doesn't matter).
>> 
>> What this means is we may be screwing up the memory by changing/omitting common block entries?
>> That's not good (or, I can't see right away why this should be benign).
>> 
>>> In external_forcing_surf.F
>>> I had to add 
>>> 161	CMM(
>>> 162	CADJ STORE EmPmR = comlev1, key = ikey_dynamics,  kind = isbyte
>>> 163	CMM)
>>> Can/should this be added to main code (perhaps with an ifdef ALLOW_BLING around it. Though I am surprised DIC doesn’t need this too.)
>> 
>> Hard to know without knowing details of bling.
>> But seems fine with me to commit to main branch with the bracket you suggest.
>> 
>> Cheers
>> -Patrick
>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>> 
>> 
>> --------------------------------------------------------
>> Patrick Heimbach, Ph.D. | http://heimbach.wordpress.com
>> 
>> * The University of Texas at Austin *
>> The Institute for Computational Engineering and Sciences
>> Institute for Geophysics | Jackson School of Geosciences
>> 201 East 24th Street, POB 4.232 | Austin, TX 78712 | USA
>> FON: +1-512-232-7694 | Email: heimbach at utexas.edu
>> 
>> * Massachusetts Institute of Technology *
>> Department of Earth, Atmospheric, and Planetary Sciences
>> 77 Massachusetts Ave, 54-1420 | Cambridge MA 02139 | USA
>> FON: +1-617-253-5259 | Email: heimbach at mit.edu
>> --------------------------------------------------------
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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, Ph.D. | http://heimbach.wordpress.com

* The University of Texas at Austin *
The Institute for Computational Engineering and Sciences
Institute for Geophysics | Jackson School of Geosciences
201 East 24th Street, POB 4.232 | Austin, TX 78712 | USA
FON: +1-512-232-7694 | Email: heimbach at utexas.edu

* Massachusetts Institute of Technology *
Department of Earth, Atmospheric, and Planetary Sciences
77 Massachusetts Ave, 54-1420 | Cambridge MA 02139 | USA
FON: +1-617-253-5259 | Email: heimbach at mit.edu
--------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1849 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20160917/c79a8bbd/attachment.p7s>