[MITgcm-support] Adjoint BOTTOMDRAG_CONTROL, adbottomdragfld : can't get non-zero sensitivity (Nidia Martinez)
Patrick Heimbach
heimbach at MIT.EDU
Wed Jul 13 02:46:33 EDT 2011
Hi Chris,
it looks like you've started from a bad verification experiment.
You picked the one which is an example (unfortunately incomplete)
on how to add a new control var. or cost term.
Because of that, code_ad/ contains a few modified/customized files
which are out-of-date compared to the defaults.
For example, file adjoint_hfluxm
is out-of-date compared to the default in
tools/adjoint_options/adjoint_default
Given your problems, we should re-think how to make this
tutorial less error-prone, or direct people to other tutorials
if they don't want to add new control variables.
Regarding ALLOW_BOTTOMDRAG_COST it depends on what you'd like to do:
If you only want sensitivities, this shouldn't be needed.
If you want to estimate it and penalize first-guesses then it's good to use it.
As Martin says, you then need to provide a prior error.
But even if you do, that contribution should initially be zero (i.e. "no effect")
because your deviation from first-guess is initially zero.
-p.
On Jul 13, 2011, at 2:07 AM, Martin Losch wrote:
> Hi Chris,
>
> great, so this means, that your netcdf fixes work as well? If so, I will check them in. Maybe you could send me your files pkg/autodiff/autodiff_ini_model_io.F, and addummy_in_stepping.F
>
> ALLOW_BOTTOMDRAG_COST is not required for bottom drag as control parameter. It adds a term to the cost function (basically penalizes deviations from first guess bottom drag). In order to make it active, you need to specify non-zero weights etc.
>
> Martn
>
> On Jul 12, 2011, at 6:06 PM, Chris Wilson wrote:
>
>> 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
>>> *********************************************
>>
>> _______________________________________________
>> 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
---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1420 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
More information about the MITgcm-support
mailing list