[MITgcm-devel] optim_numbmod: parameters in data.optim

[Matthew Mazloff]

I think its a great idea!

-Matt


On Mar 28, 2012, at 2:22 AM, Martin Losch wrote:

> Hi Holly,
>
> dfmin was somewhat inspired from m1qn3 (<http://www-roc.inria.fr/~gilbert/modulopt/optimization-routines/m1qn3/m1qn3.html 
> >, lsopt's successor, which I used a lot before I was sucked into  
> the MITgcm-affairs. However, I just realized that the parameter  
> there is called df1 and is the absolute expected decrease. So maybe  
> a better name would be dfcFrac or so?
>
> Anyway, no-one else seems to be too excited about it? And using  
> shell scripts to set fmin in data.optim is an obvious solution that  
> I didn't even think about ...
>
> Martin
>
> On Mar 27, 2012, at 11:58 AM, Holly Dail wrote:
>
>> Martin -
>>
>> I can't speak to your question about ff, but I did want to say this  
>> seems like a great idea to me (assuming there is no technical  
>> issue).  Like many perhaps, I have a script that does this  
>> automatically, but floating point math isn't so obvious in shell  
>> scripts so this option would be helpful for many.
>>
>> Would it be more intuitive to specify the converse -- 90% instead  
>> of 10% (could call it fminFrac or fminPct).  That would fit better  
>> with the current fmin construct.
>>
>> Holly
>>
>> On Mar 27, 2012, at Mar 27 , 4:22 AM, Martin Losch wrote:
>>
>>> Hi there,
>>>
>>> I would like to add a new parameter to data.optim.
>>> Rather than specifying the expected optimized cost function value  
>>> "fmin", I'd like to be able to specify a relative reduction, i.e.  
>>> have something like dfmin = 0.1 for an expected decrease of 10%.  
>>> This, to my mind, is much easier to do, especially, if you look at  
>>> a series of optimization runs, where the initial cost function  
>>> value is different between experiments by orders of  magnitude.  
>>> Don't worry, fmin, will still be there and usable, I just want to  
>>> add this option.
>>>
>>> Now, for this to work I need the cost function value as computed  
>>> by the model. This value is both in ecco_cost_* and ecco_ctrl_*,  
>>> and it's read by optim_readdata.F (fileff), and optim_readdata is  
>>> called from optim_numbmod, which would give me an easy way of  
>>> computed fmin=(1-dfmin)*ff.
>>> But unfortunately only for the "costname"-file, ff is returned as  
>>> ff=fileff, for the ctrlname-file ff=0. I was wondering, if this is  
>>> really necessary, or whether I can just return ff=fileff each time  
>>> optim_readdata is called. I could also choose to return it  
>>> whenever lheaderonly=.true. (as it is the case when called from  
>>> optim_numbmod). I have the impression, from the output of optim.x,  
>>> that neither of these changes, changes the output. Would you  
>>> expect any changes in the results if ff=fileff is returned to  
>>> optim_numbmod?
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel