[MITgcm-devel] balancing ctrl-obcs-flow

[Matthew Mazloff]

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.

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...

A nice thing about the decomposition -- if you want balance you only  
have to deal with the barotropic mode...

-Matt







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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110311/81f2f701/attachment.htm>