[MITgcm-devel] bling adjoint example
Matthew Mazloff
mmazloff at ucsd.edu
Sat Sep 17 14:38:11 EDT 2016
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
More information about the MITgcm-devel
mailing list