[MITgcm-support] Adjoint BOTTOMDRAG_CONTROL, adbottomdragfld : can't get non-zero sensitivity (Nidia Martinez)

Tue Jul 12 12:06:06 EDT 2011

Hi Martin, Nidia,

Thanks for all your help.  The problem is now fixed.

Martin, following your advice I found that taf_ad.log did not contain xx_bottomdragfld or xx_bottomdrag_dummy.    In fact, I realised that I needed to edit my adjoint control file:
verification/tutorial_global_oce_optim/code_ad/adjoint_hfluxm to alter xx_bottomdragfld to xx_bottomdrag_dummy and rebuild the Makefile.   I had been slightly confused over that previously.
That solved the problem and I can even get finite bottomdrag sensitivity in the netCDF output.

Nidia, I followed your recipe (it's very reassuring to know that we're on the same track) and found that the only difference from what I had tried so far was that I hadn't included 
#define  ALLOW_BOTTOMDRAG_COST
in ECCO_CPPOPTIONS.h

Strangely, this option seems to have no effect on the bottomdrag sensitivity.   I still need to work out why that is the case, but wanted to post a reply before I leave today.

I'm really grateful to you both for helping to fix my final adjoint problem.

Best wishes,

Chris

> 
> 
> Message: 3
> Date: Mon, 11 Jul 2011 12:36:09 -0700
> From: Nidia Martinez <nidiamartinez at ucsd.edu>
> To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] Adjoint BOTTOMDRAG_CONTROL,
>        adbottomdragfld : can't get non-zero sensitivity
> Message-ID: <4E1B50A9.80701 at ucsd.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi Chris,
> 
> I am using the bottom drag as a control and it works just fine.
> I can't help with the netcdf part because I don't use that. But I do get
> binaries with non-zero sensitivities to bottomdrag.
> 
> I switched it on in ECCO_CPPOPTIONS.h and I added the file in data.ctrl
> to be written.
> 
> #define ALLOW_BOTTOMDRAG_COST
> #define ALLOW_BOTTOMDRAG_CONTROL
> 
> then in data.ctrl add:
> xx_bottomdrag_file = 'xx_bottomdrag',
> 
> I get non-zero sensitivities:
> bottomdrag = rdmds([dpath 'adxx_bottomdrag.0000000000.001.001']);
> 
> 
> The only thing is that I get recomputation:
> TAF RECOMPUTATION WARNING CALL_STMT ad_input_code.f:402426 in the_main_loop
> TAF RECOMPUTATION WARNING CALL_STMT ad_input_code.f:402426 in the_main_loop
> 
> But since the running time with or without the bottom drag on takes the
> same time, I guess that recomputation is harmless and I didn't really
> bother to solve it.
> 
> I hope this helps,
> Nidia
> 
>> 
>> On Jul 7, 2011, at 6:13 PM, Chris Wilson wrote:
>> 
>> 
>>> Hi,
>>> 
>>> I'm trying to find the sensitivity of free-surface height at a point to particular control variables.
>>> For many control variables, e.g. velocity, wind stress, eta, this works fine and plausible non-zero sensitivities are found in both the binary and netCDF output (adstate*.nc).
>>> 
>>> However, when I try to switch on bottom drag as a control variable (ALLOW_BOTTOMDRAG_CONTROL), it seems that I need to add some extra code to get the model to write the that sensitivity to the netCDF file:
>>> 
>>> i.e. in pkg/autodiff/autodiff_ini_model_io.F, I need to add something like
>>> 
>>> #ifdef ALLOW_BOTTOMDRAG_CONTROL
>>>      CALL MNC_CW_ADD_VNAME('adbottomdragfld', 'Cen_xy_Hn__-__t',
>>>     .3,4, myThid)
>>>      CALL MNC_CW_ADD_VATTR_TEXT('adbottomdragfld',
>>>     &      'units','[cost]/[N/m^2]', myThid)
>>>      CALL MNC_CW_ADD_VATTR_TEXT('adbottomdragfld','long_name',
>>>     &      'adjoint bottom_drag', myThid)
>>>      CALL MNC_CW_ADD_VATTR_TEXT('adbottomdragfld',
>>>     &      'coordinates','XC YC RC iter', myThid)
>>> #endif
>>> 
>>> 
>>> and in pkg/autodiff/addummy_in_stepping.F, I need to add something like
>>> 
>>> #ifdef ALLOW_BOTTOMDRAG_CONTROL
>>>          CALL MNC_CW_RL_W('D','adstate',0,0,'adbottomdragfld',
>>>     .adbottomdragfld, myThid)
>>> #endif
>>> 
>>> -----
>>> This is perhaps an aside from the real issue, that whatever I try I cannot get a non-zero adjoint sensitivity w.r.t. bottom drag, in either the netCDF or binary output.  I include the netCDF aside because I'm reluctant to remove the changes and, if I'm not wrong, they make me question whether other code tweaks might be needed for bottom drag sensitivity to work correctly.
>>> 
>>> ->>  Could anyone please recommend a recipe for
>>> 
>>> a) switching on this adjoint sensitivity successfully
>>> 
>>> or
>>> 
>>> b) choosing the correct runtime/buildtime flags to make sure the sensitivity is non-zero?
>>> 
>>> 
>>> Thanks,
>>> 
>>> Chris W
>>> 
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>> 
> 
> --
> ------------------------------------------------------------------------------
> Nidia Martinez Avellaneda, Ph.D.
> Scripps Institution of Oceanography
> University California San Diego
> 9500 Gilman Drive, La Jolla, CA 92093-0230
> 
> Phone:   +1 858-822-7692
> E-mail:  nidiamartinez at ucsd.edu
> ------------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi All,
> ?
> I am? (re)calculating theta in the temperature transport equation ( equation 2.166 of manual) implemented in? gad_calc_rhs.F using the diagnostics ( advective?& diffusive fluxes of potential temperature?and transports)? and?i am ending up with a?difference?between the instantaneous theta calculated by the MITgcm solver and theta recalculated using the diagnostics.? I am unable to figure out the mistake I am making with the diagnostics. Any help is most welcome.
> ?
> The tutorial is : tutorial_global_oce_latlon ( global ocean simulation at 4deg resolution with GMREDI scheme). I am focusing on the second layer. Thus there is no external forcing.
> ?I am using this bit of fortran code from gad_calc_rhs.F as a guide?to calculate gTracer :
> //////////////////////////////////////////////////////////////////////
> ?gTracer(i,j,k,bi,bj)=gTracer(i,j,k,bi,bj)
> ???? &?? -_recip_hFacC(i,j,k,bi,bj)*recip_drF(k)
> ???? &?? *recip_rA(i,j,bi,bj)*recip_deepFac2C(k)*recip_rhoFacC(k)
> ???? &?? *( (fZon(i+1,j)-fZon(i,j))
> ???? &???? +(fMer(i,j+1)-fMer(i,j))
> ???? &???? +(fVerT(i,j,kDown)-fVerT(i,j,kUp))*rkSign
> ???? &???? -localT(i,j)*( (uTrans(i+1,j)-uTrans(i,j))
> ???? &?????????????????? +(vTrans(i,j+1)-vTrans(i,j))
> ???? &?????????????????? +(rTransKp1(i,j)-rTrans(i,j))*rAdvFac
> ???? &????????????????? )*advFac
> ???? &??? )
> ///////////////////////////////////////////////////////////////
> 
> fZon=ADVx_TH + DFxE_TH ; from 2nd layer 2
> fMer=ADVy_TH + DFyE_TH; from 2nd layer 2
> fVerT(i,j,kDown)=ADVr_TH+DFrE_TH from bottom of 2nd layer
> fVerT(i,j,kUp)???? =ADVr_TH+DFrE_TH from top of 2nd layer
> For the transports, i multiply the velocity diagnostics with the respective?area (The transport terms? play only a small role). All diagnostics are averaged montly. So the change in theta after 1month is gTracer*1month (in seconds)? with the gTracer calculated from averaged diagnostics. But this value (change in theta) is different when I calculate with instantaneous theta output by the solver.
> ?
> My data.diagnostics file, say for,?for ADVr_TH averaged for 1 month is here :
> 
> ?
> ?&diagnostics_list
> ? frequency(1) = 2592000,
> ? fields(1,1)= 'ADVr_TH',
> ?? filename(1) = 'flux',
> ?&
> ?
> Thanks in advance
> Krishnakumar
> ?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20110711/ce002c9f/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> End of MITgcm-support Digest, Vol 97, Issue 8
> *********************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20110712/9256511e/attachment-0001.htm>