[MITgcm-support] coldstart option for m1qn3

[Daniel Goldberg]

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: D <dgoldber at mit.edu>an.Goldberg at ed.ac.uk
web: http://ocean.mit.edu/~dgoldberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20141026/052a9b13/attachment.htm>