[MITgcm-devel] balancing ctrl-obcs-flow

Matthew Mazloff mmazloff at ucsd.edu
Mon Mar 14 12:38:43 EDT 2011 

Hi Martin,

Yes, only the ctrl_get and ctrl_ini parts need to be checked in for  
the modes code to be available.

And I agree that if obcs balance is a strong constraint this will  
likely not have any problems with obcs controls that I can foresee.

The problem is, as I think you know, when a soft constraint has a  
barotropic signal it releases a tidal wave of strong sensitivity.   
This can ill-condition the problem as smaller baroclinic sensitivities  
are hidden.  Constraints on bottom pressure, SSH, and, I would assume,  
volume conservation can cause these strong sensitivities.

By decomposing each column into modes you can down-weight this  
barotropic sensitivity without losing any degrees of freedom in the  
problem.  Also, by giving the barotropic sensitivity a very small  
weight you will have minimal changes to net volume and a large penalty  
on these changes.

I have never used the ALLOW_CTRL_OBCS_BALANCE option and agree it is  
probably fine to remove it along with ctrl_obcsvol.F, ctrl_volflux.F  
and ctrl_obcsbal.F

-Matt






On Mar 14, 2011, at 2:00 AM, Martin Losch wrote:

> Hi Matt,
>
> On Mar 11, 2011, at 6:40 PM, Matthew Mazloff wrote:
>
>> Hi Holly,
>>
>> The barotropic/baroclinc decomposition code for obcs ctrls was up  
>> to date about 2 months ago -- its here:
>> http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/SOSE/BoxAdj/
>> I could quickly bring it back to date if you want to use it (or if  
>> someone wants to check it in).  Though I agree that ctrl_volflux,  
>> ctrl_obcsbal and ctrl_obcsvol are unnecessary -- or need to be  
>> fixed --  and if this is gonna happen I will wait to update my code  
>> until after the cleaning.
> As far as I can see: The cost_obcs.F and cost_obcse/w/n/s.F in your  
> SOSE/BoxAdj are already part of the main repository. Your version of  
> ecco_cost_final.F seems to be a (benign) bug fix and can go into the  
> repository strait away. Only the ctrl_getobcs?.F (and the init file)  
> have different code. Is that correct?
>
>> In my experience, if you are optimizing to anything with a  
>> barotropic signal (e.g. SSH) you need this decomposition code to  
>> well condition the problem.  Otherwise barotropic sensitivities are  
>> huge -- and a constraint on volume will not be enough.  Actually, I  
>> have never had success with a volume constraint, but maybe its  
>> cause I always had SSH involved.  My concern with volume constraint  
>> is that it will have no influence until volume gets out of balance,  
>> then it will creates a strong restoring barotropic sensitive and  
>> overshoot your intended balance...but maybe I am just being  
>> pessimistic...
> I have not as much experience with this as you do, but if you  
> include volume conservation (balancing) as a strong constraint (to  
> be satified exactly), as is done now with Jean-Michel's code (and I  
> did not yet try it in an adjoint experiment, but I have my own code  
> which does basically the same for a specific situation and that  
> works well), then the inflow through the open boundaries will be  
> balanced, just in the same way the momentum equations are satisfied.  
> Right? If you have more than one open boundary, this balanced flux  
> can still lead to a strong barotropic signal in the control  
> variables as the vertically averaged flow (might) adjust to SSH data  
> easily. In that case you might want to control/constrain the extra  
> net inflow (caused by the ctrl-innovation) through individual  
> boundaries as it is done in the  ALLOW_CTRL_OBCS_BALANCE code. But  
> this is already done to some extend in cost_obcs?.F where the  
> deviation from the first guess in penalized. So using these two  
> things together doesn't make too much sense to me (without trying it).
>
> I again suggest removing the old and partially wrong/broken code  
> (ctrl_obcsvol.F, ctrl_volflux.F and ctrl_obcsbal.F along with  
> everything that is within ALLOW_CTRL_OBCS_BALANCE cpp-flags). The  
> current configurations that I am aware of (SOSE and Holly's set up  
> and my stuff anyway) do not rely on this code. After this clean-up,  
> Matt can update his code, and possibly check it into the main  
> repository?
>
> If I do not hear from you, I'll do these changes this afternoon ...
>
> Martin
>
>> On Mar 11, 2011, at 6:05 AM, Holly Dail wrote:
>>
>>> Martin -
>>>
>>> Here's my take on things -- from previous conversations with Matt  
>>> and Patrick mostly.
>>>
>>> - As far as I can tell, the code surrounded by  
>>> ALLOW_CTRL_OBCS_BALANCE, OBCS_VOLFLUX_COST_CONTRIBUTION, and  
>>> BAROTROPIC_OBVEL_CONTROL is all Jake Gebbie's from his thesis.  It  
>>> all assumes that the top-most level of the OBCS velocity controls  
>>> contains the unbalanced barotropic component, and that the rest of  
>>> the velocity structure is all balanced.  It also assumes the  
>>> existence of a northern boundary.  The goal of his work was  
>>> important -- allow independent control of barotropic and  
>>> baroclinic structure, which according to Matt Mazloff is  
>>> especially necessary when constraining to SSH or bottom pressure.
>>>
>>> - Matt has written code to allow more direct treatment of these  
>>> issues via using barotropic and baroclinic modes as controls, and  
>>> eventually it would be great to see that code incorporated.  Matt  
>>> - are there reasons that this might not be integrateable at some  
>>> point?
>>>
>>> - Balancing total flux (applied + controls) at the beginning of  
>>> the run using JMC's new code (ALLOW_OBCS_BALANCE) is good, but not  
>>> the same thing re. the adjoint as penalizing unbalanced control  
>>> variables via a cost function.  Thus a cost term penalizing  
>>> misbalance is a good idea.  cost_obcsvol.F as currently written  
>>> relies on the above assumptions (top level of velocity field  
>>> contains barotropic component) and so can not be used as is.
>>>
>>> It seems that cleaning up now in anticipation of someday adding  
>>> Matt's modes code is a good idea.  So my feeling is that you  
>>> should go ahead and remove ctrl_obcsvol.F, ctrl_volflux.F and  
>>> ctrl_obcsbal.F and clean out the ALLOW_CTRL_OBCS_BALANCE pieces of  
>>> ctrl_getobcs?.F.  You could leave cost_obcsvol in place but maybe  
>>> add an exit or something so noone uses it as is.  Then someone can  
>>> fix it up later?
>>>
>>> Holly
>>>
>>>
>>> On Mar 11, 2011, at Mar 11 , 8:28 AM, Martin Losch wrote:
>>>
>>>> Hi there,
>>>>
>>>> while going through the ctrl-code, I observed a few  
>>>> inconsistencies, all are related to the balancing, or  
>>>> conservation of flow into the domain.
>>>>
>>>> Jean-Michel has now nicely implemented a very general way of  
>>>> balancing the flow through open boundaries at every time step  
>>>> (for any flow through the open boundaries). This routine  
>>>> (obcs_balanace_flow.F) is called at the end of obcs_calc.F, so  
>>>> after any of the ctrl_getobcs* are called (in  
>>>> obcs_prescribe_read), therefore it also includes the ctrl- 
>>>> contribution of the obcs-velocities.
>>>>
>>>> As far as I can see, this new code makes the code within  
>>>> ALLOW_CTRL_OBCS_BALANCE in ctrl_getobcs?.F obsolete, along with  
>>>> the routines ctrl_obcsbal.F and ctrl_volflux.F (in this code the  
>>>> "global" net inflow is computed and converted into a velocity  
>>>> shiftvel, and then this shiftvel is added to the northern inflow  
>>>> to balance the system, the ALLOW_CTRL_OBCS_BALANCE code balances  
>>>> the flow for each boundary individually). Further, the flux  
>>>> computations are most likely missing hFac's. I suggest to remove  
>>>> this code (makes the entire interaction of ctrl and obcs much  
>>>> easier to comprehend).
>>>>
>>>> There is a third routine, called ctrl_obcsvol.F, that seems to be  
>>>> the  combination of ctrl_obcsbal.F and ctrl_volflux. This routine  
>>>> is never called anywhere in the code. I suggest to remove it in  
>>>> any case.
>>>>
>>>> in pkg/ecco there is also a cost_obcsvol, which makes the global  
>>>> balance a weak constraint. This is a useful option and should be  
>>>> kept.
>>>>
>>>> There are no verification experiments to test this, so I need  
>>>> input from people who use obcs as control variables (Holly, Matt,  
>>>> who else?)
>>>>
>>>> Summary of my suggestions:
>>>> 1. remove ctrl_obcsvol.F, it's never called and it seems to do  
>>>> the same as ctrl_volflux and ctrl_obcsbal
>>>> 2. remove ctrl_volflux and ctrl_obcsbal, they are probably  
>>>> incomplete, and they are superseded by obcs_balance_flow
>>>> 3. keep ecco/cost_obcsvol.F, as it is a useful constraint that  
>>>> can be used instead of the exact balancing in obcs_balance_flow
>>>>
>>>> Please let me know, what you think? Can I do 1. and 2.?
>>>>
>>>> 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
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list