[MITgcm-devel] [MITgcm-cvs] CVS Commit MITgcm_contrib/mlosch/optim_m1qn3

[Martin Losch]

Hi Matt and other optimizers,

the reason that this is only in the contrib area right now is, that I am still not confident that it will work properly in all situations. So far I have two experiences, one, where it worked much better than lsopt (basically lsopt stalls after a few simulations, when m1qn3 keeps reducing the costfunction) and a second case, where lsopt does much better within a given number of simulations (20). In the second case m1qn3 needs some simulations within the line search routine (that's where lsopt fudges it and just repeatedly reads in the results from the same simulation), which is normal in the beginning, but already in iteration 5, there are more than 8 simulations, which shouldn't happen so early on. Either the gradient in that simulation is not very good, or I my messing with the line search routine does something bad to m1qn3. In the first case where m1qn3 is doing better than lsopt, very few simulations within the line search are required. 

Am I talking some Babylonic lingo? Never mind the details. You (all of you) are very welcome to try this code. Compiling is simpler than lsopt/optim:
Edit the Makefile to adjust to your system/compiler and change the include path to point to your build directory (just as in optim/Makefile), make depend && make

the resulting optim.x (same name) takes the same input files and most of the variables in data.optim can stay as they are (so far, I plan to have a separate data.m1qn3 and not use data.optim any more, but for now it's easier for comparisons). There are only TWO things that require attentioin:
- numiter (in data.optim) must be larger than one. It is now the number if optimization iterations that you are going to allow ***in total***. I'd put something large, like 1000
- m1qn3 produces an output file (m1qn3_output.txt, the name is hard coded) that is being reopen each time you run optim.x, so make sure that you keep or restore a copy in the working directory. One could modify optim_sub.F to redirect the m1qn3 output to stdout. I like it better this way (now).

I think that's all you have to do in order to use optim_m1qn3.

Martin




On Apr 26, 2012, at 6:21 PM, Matthew Mazloff wrote:

> Hi Martin
> 
> I am very interested in this -- are you planning on checking in any additional documentation to explain how use of this package differs from the original optim.  Or should it be obvious when I give it a try...
> 
> Thanks for adding this!
> -Matt
> 
> 
> On Apr 26, 2012, at 4:10 AM, Martin Losch wrote:
> 
>> Update of /u/gcmpack/MITgcm_contrib/mlosch/optim_m1qn3
>> In directory forge:/tmp/cvs-serv29317
>> 
>> Added Files:
>> 	Makefile ddot.F m1qn3_common.h m1qn3_offline.F m1qn3a_common.h
>> 	mlis3_common.h optim.h optim_main.F optim_readdata.F
>> 	optim_readparms.F optim_store_m1qn3.F optim_sub.F
>> 	optim_writedata.F
>> Log Message:
>> First working version of a new optimization package that uses a slightly
>> modified version of m1qn3, v3.3
>> (https://who.rocq.inria.fr/Jean-Charles.Gilbert/modulopt/optimization-routines/m1qn3/m1qn3.html)
>> to work as an offline optimizer. The advantage of m1qn3_offline is, that
>> it is run in reverse communication control mode, so that it gives back
>> control to the call routine (here a script) to provide a new estimate of the
>> cost function and the gradient based on the control vector. This way we can
>> do complete line searches that are meaningful.
>> 
>> 
>> 
>> _______________________________________________
>> MITgcm-cvs mailing list
>> MITgcm-cvs at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel