[MITgcm-devel] optim_numbmod: parameters in data.optim

[Patrick Heimbach]

Sorry, by "go this way" I meant to remove everything in the
pkg/ctrl/optim_readparms.F namelist except optimcycle.

Indeed, it could also be moved to ctrl_readparms.F
but that would destroy backward compatibility with many setups,
so better for now to keep the data.optim file.

p.

On Mar 29, 2012, at 9:40 AM, Martin Losch wrote:

> Hi Patrick et al,
> 
> Ok, will do it then, maintaining backward compatibility (maybe not this week nor next week).
> 
> what to you mean by "go this way"? Keep it as it is and regularily check, if the namelists are consistent (use the optim_numbmod.F as a reference)? Fine with me, but I'll update the namelist in optim_readparams.F
> Alternatively, one could move optimcycle into a separate namelist and have nothing else in optim_readparms.F, but that would require changing set ups, and I don't think that this would go down too well.
> 
> Martin
> 
> On Mar 29, 2012, at 3:23 PM, Patrick Heimbach wrote:
> 
>> Hi Martin,
>> 
>> good idea regarding percentage decrease, 
>> as long as it's implemented in a way backward compatible
>> (e.g., check whether absolute or precentage cost decrease is specified).
>> 
>> Re. namelists, the differences start occurring after we split the optim
>> part into a separate executable (previously they were part of the same).
>> In fact, the optim part in pkg/ctrl shouldn't need anything apart from 
>> "optimcycle", and I'd prefer to rather go this way
>> (makes it clear that nothing else is needed by the mitgcmuv_ad executable).
>> We usually do NAMELIST declarations in the .F files, not the .h
>> 
>> p.
>> 
>> On Mar 27, 2012, at 4:41 AM, Martin Losch wrote:
>> 
>>> BTW, shouldn't the namelists in optim/optim_numbmod.F and pkg/ctrl/optim_readparms.F be the same?
>>> Currently the are not:
>>> optim/optim_numbmod.F:
>>>    namelist /OPTIM/
>>>   &                      optimcycle,
>>>   &                      numiter, nfunc, fmin, iprint,
>>>   &                      epsf, epsx, epsg,
>>>   &                      nupdate, eps
>>> pkg/ctrl/optim_readparms.F:
>>>    namelist /optim/
>>>   &                 optimcycle, nvars,
>>>   &                 nondimcontrol,
>>>   &                 numiter, nfunc, fmin, iprint,
>>>   &                 epsf, epsx, epsg,
>>>   &                 nupdate, eps
>>> 
>>> One could easily fix that be moving the namelist definitions into optim.h, as this file is sourced by both subroutines (and the same should be true for ctrl.h). Are there any good reasons for not having them defined twice?
>>> 
>>> Martin
>>> 
>>> On Mar 27, 2012, at 10:22 AM, Martin Losch wrote:
>>> 
>>>> Hi there,
>>>> 
>>>> I would like to add a new parameter to data.optim.
>>>> Rather than specifying the expected optimized cost function value "fmin", I'd like to be able to specify a relative reduction, i.e. have something like dfmin = 0.1 for an expected decrease of 10%. This, to my mind, is much easier to do, especially, if you look at a series of optimization runs, where the initial cost function value is different between experiments by orders of  magnitude. Don't worry, fmin, will still be there and usable, I just want to add this option.
>>>> 
>>>> Now, for this to work I need the cost function value as computed by the model. This value is both in ecco_cost_* and ecco_ctrl_*, and it's read by optim_readdata.F (fileff), and optim_readdata is called from optim_numbmod, which would give me an easy way of computed fmin=(1-dfmin)*ff.
>>>> But unfortunately only for the "costname"-file, ff is returned as ff=fileff, for the ctrlname-file ff=0. I was wondering, if this is really necessary, or whether I can just return ff=fileff each time optim_readdata is called. I could also choose to return it whenever lheaderonly=.true. (as it is the case when called from optim_numbmod). I have the impression, from the output of optim.x, that neither of these changes, changes the output. Would you expect any changes in the results if ff=fileff is returned to optim_numbmod?
>>>> 
>>>> Martin
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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 | 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
>> 
>> 
>> 
>> _______________________________________________
>> 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 | 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