[MITgcm-support] coldstart option for m1qn3

[Martin Losch]

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