[MITgcm-support] coldstart option for m1qn3

[Martin Losch]

Hi Dan,

I don’t like the fmin parameter (for the reason that you experienced just now: it isn’t a universally useful parameter), but I kept it for compatibility with the “other” optim packages.
Please have a look at optim_readparms.F. if you do NOT fmin, then the “ff” value (the last cost function value) is used.
For optimCycle = 0 I prefer to use fminFrac (by how big a fraction do I expect the cost function value to decrease, e.g. by 10% -> fminFrac = 0.1), but that does only work, when fmin is unset.

Sorry for not documenting any of this, I wasn’t sure that anyone would ever use this code.

Martin


On Oct 26, 2014, at 11:15 AM, Daniel Goldberg <dngoldberg at gmail.com> wrote:

> Hi Martin
> 
> Thanks for the response. I was referring to this implementation, it is the only one I have ever used in fact.
> 
> I have tried this out -- i.e. the control files for iteration 19 contained "bad" values, and so I set optimcycle back to 18 and re-ran optim.x with the appropriate cost files and coldStart=.true, no other changes to data.optim (except fmin, see below).
> 
> It turns out that I *did* in fact need to update fmin to a value smaller than the next lowest cost function value (actually I am not sure if it is the next smallest, or just the previous), as I got the typical message one gets if fmin .gt. fc.
> 
> Thanks
> Dan
> 
> On Fri, Oct 24, 2014 at 2:42 PM, Martin Losch <Martin.Losch at awi.de> wrote:
> Hi Dan,
> 
> you are refering to this <http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/mlosch/optim_m1qn3/> implementation?
> 
> Sometimes, when an optimization get’s stuck, it may be useful to give the system a godd kick and let it settle again. the coldstart flag is one way to try this, and you are right, it causes m1qn3 to forget all previous information stored in the approximated inverse hessian (dz?). Basically it then restarts the optimization at the last successful iteration, as if this was the first guess (but the fmin information does not need to be supplied again, if I am not mistaken), so that you could change nupdate (but that’s usually not a parameter that I tinker with a lot).
> 
> Martin
> 
> On Oct 24, 2014, at 1:36 PM, Daniel Goldberg <dngoldberg at gmail.com> wrote:
> 
> > Hi All
> >
> > I have not used the coldstart option before with optim_m1qn3, as I was not sure exactly what it does. My thought is that the executable (optim.x) is called as if it is being called for the first time, forgetting any previous iterates -- i.e. it is as if all input files were updated with the relevant controls (e.g. xx_genarr2d_**), and the optimisation process were started again with "optimcycle=0", and i would be free to change parameters such as "nupdate". (presumable fmin would need to be updated as well.)
> >
> > Is this indeed the case, or does coldstart do something different when applied to m1qn3?
> >
> > Many thanks
> > Dan
> >
> > --
> >
> > Daniel Goldberg, PhD
> > Lecturer in Glaciology
> > School of Geosciences, University of Edinburgh
> > Geography Building, Drummond Street, Edinburgh EH8 9XP
> >
> >
> > em: Dan.Goldberg at ed.ac.uk
> > web: http://ocean.mit.edu/~dgoldberg
> > _______________________________________________
> > 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
> 
> 
> 
> -- 
> 
> Daniel Goldberg, PhD
> Lecturer in Glaciology
> School of Geosciences, University of Edinburgh
> Geography Building, Drummond Street, Edinburgh EH8 9XP
> 
> 
> em: Dan.Goldberg at ed.ac.uk
> web: http://ocean.mit.edu/~dgoldberg
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support