[MITgcm-support] tutorial_global_oce_optim optimisation failed

Matthew Mazloff mmazloff at ucsd.edu
Mon Apr 30 17:54:16 EDT 2018


Well you are correct that its not actually taking a step because the dot product of the control is 0:
>> norm of x................... 0.00000000E+00
meaning the controls are all 0 still.

However the gradients are non-zero
>> norm of g................... 0.12730927E-01
so the linesearch should step and 
ecco_ctrl_MIT_CE_000.opt0001 
should not be all zero. 

To debug this you could put a print statement in optim_writedata.F to see what it is writing…..

I don’t know enough about this tutorial to be a bigger help, sorry

Matt


> On Apr 30, 2018, at 2:50 PM, Andrew McRae <andrew.mcrae at physics.ox.ac.uk> wrote:
> 
> Yes, I did.
> 
> On 30 April 2018 at 22:42, Matthew Mazloff <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
> This is still iteration 0. You have to update data.optim to tell it you are now at iteration 1
> 
> Matt
> 
> 
>> On Apr 30, 2018, at 2:38 PM, Andrew McRae <andrew.mcrae at physics.ox.ac.uk <mailto:andrew.mcrae at physics.ox.ac.uk>> wrote:
>> 
>> I tried a few steps of this, but the output of optim.x always has
>> 
>>   cost function............... 0.62002323E+01
>>   norm of x................... 0.00000000E+00
>>   norm of g................... 0.12730927E-01
>> 
>> near the end, with no decrease in the cost function.  So I guess it's not actually taking the step?
>> 
>> Andrew
>> 
>> On 27 April 2018 at 18:04, Andrew McRae <andrew.mcrae at physics.ox.ac.uk <mailto:andrew.mcrae at physics.ox.ac.uk>> wrote:
>> !!!  Okay...
>> 
>> Yes, it produced the .opt0001 file.  I'll see how this goes.
>> 
>> Thanks,
>> Andrew
>> 
>> On 27 April 2018 at 17:57, Matthew Mazloff <mmazloff at ucsd.edu <mailto:mmazloff at ucsd.edu>> wrote:
>> Hello
>> 
>> Its been awhile, but I am pretty sure that is the normal output. It says “fail", but it did give you a new and ecco_ctrl_MIT_CE_000.opt0001 (correct?) and if you unpack and run likely the cost will descend.
>> 
>> I think it worked correctly. lsopt/optim are just confusing…but I think its working. I think all is good!
>> 
>> Matt
>> 
>> 
>> 
>>> On Apr 27, 2018, at 8:25 AM, Andrew McRae <andrew.mcrae at physics.ox.ac.uk <mailto:andrew.mcrae at physics.ox.ac.uk>> wrote:
>>> 
>>> Just separating this from the other thread <http://mailman.mitgcm.org/pipermail/mitgcm-support/2018-April/011521.html>, I got the bundled MITgcm optim routine built (having made these changes <https://github.com/MITgcm/MITgcm/compare/master...dorugeber:optim_fix>, based on this <http://mailman.mitgcm.org/pipermail/mitgcm-support/2010-September/006825.html> thread from 2010 and this <http://mailman.mitgcm.org/pipermail/mitgcm-support/2016-July/010527.html> one from 2016).
>>> 
>>> I use OpenAD to create the adjoint.
>>> 
>>> My steps are:
>>> 1) in the build directory, run ../../../tools/genmake2 -oad -mods=../code_oad
>>> 2) run make depend and make adAll
>>> 3) copy input_oad/ into a new folder scratch/
>>> 4) within scratch/, run ./prepare_run
>>> 5) copy mitgcmuv_ad from build/ into scratch/, copy optim.x into scratch/OPTIM/
>>> 6) run ./mitgcmuv_ad
>>> 7) in scratch/OPTIM, create symlinks to ../data.optim and ../data.ctrl
>>> 8) copy the files ecco_cost_MIT_CE_000.opt0000 and ecco_ctrl_MIT_CE_000.opt0000 into the OPTIM subdirectory
>>> 9) run ./optim.x within the subdirectory
>>> 
>>> The full output is attached, but I assume the optimisation failed since the last lines are
>>> 
>>>   optimization stopped because :
>>>   ifail =   4    the search direction is not a descent one
>>> 
>>> Any ideas?  (I guess this isn't something that is tested in the daily builds?)
>>> 
>>> In the meantime, I'll try the m1qn3 routine as in the other thread, which should help distinguish between a problem with the optimisation routine or the gradient generated by mitgcmuv_ad.
>>> 
>>> Andrew
>>> <out.txt>_______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support <http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support>
>> 
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support <http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support>
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20180430/58616c74/attachment.html>


More information about the MITgcm-support mailing list