[MITgcm-devel] balancing ctrl-obcs-flow

[Holly Dail]

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