[MITgcm-devel] balancing ctrl-obcs-flow

[Martin Losch]

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