[MITgcm-devel] ctrl

Wed May 4 08:15:20 EDT 2011

Hi Patrick, Gael,

I think I found a problem in ctrl_map_ini_gen.F
The following call (line 101 and line 273)
      call mdsreadfield(wFileCur,32,'RL',nR,wFld3d,1,mythid)
reads a weights file with a fixed precision (32), however, this weights-file is written with active_write_*.F where the precision is determined by ctrlprec (parameter that is set in ctrl.h):
> cph ctrlprec will be set to 32 for ECCO to reduce I/O
> cph but jeopardizes some gradient checks, so should be
> cph set to 64 by default.
> cph Need to put this in namelist at some point!
>       integer     ctrlprec
> #ifdef CTRL_SET_PREC_32
>       parameter ( ctrlprec = 32 )
> #else
>       parameter ( ctrlprec = 64 )
> #endif
However, if you do not set CTRL_SET_PREC_32 (which does not appear anywhere else), this will lead to read a file with the wrong precision and I am sure (still need to test it) that this is the reason for my checkerboard pattern in my gradients after they have been run through the xxfld3d.gt.boundvec(5)/weights test in adctrl_map_ini_gen3d

What is your opinion? I think this call should be 
      call mdsreadfield(wFileCur,ctrlprec,'RL',nR,wFld3d,1,mythid)

Martin

On May 4, 2011, at 11:51 AM, Martin Losch wrote:

> Hi Patrick et al,
> 
> I have to apologize for being too hasty. Everything seems to be in order and the contribution stems from the regularization term in cost_theta0, which I totally forgot (my integration is long, 35h, so that it difficult to monitor each "event" along the way).
> 
> What remains is a checkerboard pattern in adxx_theta that I have traced back to the last block of code in adctrl_map_ini_gen3d (where adxxfld3d=0 if abs(xxfld3d) is out of bounds, although this does not happen, when I estimate this offline). I'll keep debugging my set up.
> 
> Martin
> 
> 
> On May 3, 2011, at 9:59 PM, Martin Losch wrote:
> 
>> Hi Patrick,
>> 
>> my configuration is quite simple. I use 1 CPU (for some reason with MPI), and nothing fancy, no DIVA, just "non-dimensional" controls. The problem only appears with adxx_theta and adxx_salt, surface and open boundary conditions gradients seem to be OK, so seem to be related to *_xyz routine(s). I'll have another look at ctrl_init_ctrlvar tomorrow and may send my CPP-flags.
>> 
>> Martin
>> 
>> On May 3, 2011, at 8:37 PM, Patrick Heimbach wrote:
>> 
>>> Hi Martin,
>>> 
>>> not sure.
>>> Have you checked whether your run does (or does not)
>>> do what it's supposed to do in ctrl_init_ctrlvar
>>> (namely initialize fname(2)=adxx...)
>>> 
>>> Alternatively, are you using DIVA,
>>> and have some old "costfinal" files lying around which 
>>> are meant to *prevent* (re-!) initialization?
>>> 
>>> -p.
>>> 
>>> On May 3, 2011, at 8:13 AM, Martin Losch wrote:
>>> 
>>>> Dear ctrl-ers,
>>>> 
>>>> I am having trouble with my control variables and while trying to debug my problem I learned a few things:
>>>> 
>>>> 1. At the beginning of an adjoint simulation both xx_* and adxx_* files are initialized with zeros (ctrl_init/ctrl_init_ctrlvar/ctrl_set_globfld_*). Then ctrl_unpack unpacks the ctrl-vector and writes it to xx_*. xx_* are the control variables, adxx_* are files to be filled with the gradient fields (I thought).
>>>> 2. The gradients (with respect to initial conditions) adxx_theta and adxx_salt are written at the very end of the adjoint simulation (in adctrl_map_ini[_ecco]), by calling adactive_read_xyz
>>>> 3. adactive_read_xyz (active_file_ad.F) creates fname=adxx_theta from active_var_file (xx_theta) fname=adxx_theta and calls 
>>>>   call active_read_rl( fname, adactive_var,
>>>>  &                     doglobalread, lAdInit, irec, mynr,
>>>>  &                     REVERSE_SIMULATION, myiter, mythid )
>>>> 4. active_read_rl (active_file_control.F) in REVERSE_SIMULATION mode reads from file active_var_file (=fname=adxx_theta in my example) the variable active_data_t, then add the current gradient field (active_var = adtheta in my example) to active_data_t and then writes active_data_t back to active_var_file (= adxx_theta )
>>>> 
>>>> Step 4 is necessary in some cases (e.g. when mean forcing is a control variable), but it requires that the adxx_* files contain only zeros when they are initialised/written at the beginning of the simulation. The latter does not seem to be the case in my experiments. I observe, that adxx_theta (and adxx_salt) contain nonzero values, that look like the gradient of the previous iteration, before the end of the adjoint simulation is reached (in fact from the beginning of the simulation when they are written, but I cannot figure out where this happens exactly), so that with iterations the gradient in adxx_theta accumulates. To my mind, this cannot be correct. 
>>>> 
>>>> Here's my question: Where do I go wrong? Do I misunderstand what's going on? Do I have to set a particular flag to make the model write zeros when it initialises adxx_*?
>>>> 
>>>> Martin
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>> 
>>> ---
>>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>> 
>> Martin Losch
>> Martin.Losch at awi.de
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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