[MITgcm-devel] code changes

[Martin Losch]

Hi Holly,
On Mar 10, 2011, at 3:50 PM, Holly Dail wrote:

> A caveat: I don't have any experience using the code without ALLOW_CAL, so I'm not clear on how to make these changes work for that case.
I think that's no problem. This case is handled in ctrl_get_gen_rec.F
> 
> One issue: I don't know how the code based on intercept and slope works at all, but it looks like it would likely break with periods of 0 or -12.  I've noticed this in cost_forcing_gen.F and ctrl_getrec.F (line "fac = 1. - fldsecs/fldperiod"), though if as you say ctrl_getrec.F is never called, maybe this slope/intercept code is no longer functional?  
I just made ctrl_getrec disfunctional. I could not see it being used except for code that hasn't been used in a while (it didn't even compile before my changes this week).
The "intercept and "slope" seems to be used in this context:
     &                - ( xx_gen_remo_intercept +
     &                    xx_gen_remo_slope*(irec-1)*xx_gen_period )
so xx_gen_period = 0 will work, but -12 will give a sawtooth-like behavior I guess. One could avoid this by checking the parameters in ctrl_readparms or ctrl_check.

> Hate to open other cans of worms, but there is some inconsistency in the code re. the ordering of obcs control fields.  I believe the code pieces I'm using assume the 3rd field is vvel and 4th field is uvel (i.e. they are packed T/S/V/U -- see for example ctrl_getobcss.F where OBSu is modified when iobcs is 4), while code like cost_obcsvol.F assumes they are packed T/S/U/V (which is more logical, but this code is never called from any other S/R).  I can't figure out right now which order they are packed into the control files.  I'm mostly concerned as to whether its all consistent, rather than whether its illogical.
I can only recommend to avoid code within #ifdef ALLOW_CTRL_OBCS_BALANCE. The code does not look right to me. I think Jake tried to balance both normal and tangential xx_velocities (why?) and might have mixed up things? Plus, there are definitely hfac's missing in this computation, so leave it alone. The ordering is T/S/U/V for the obcs and this is also true for the ctrl-fields. 
For balanced flow even with optimized boundary flow you can (probably) use the "forward" flags OBCSuseBalance with all the new features checked in by Jean-Michel. I am currently using an older hacked version which does effectively what Jean-Michel implemented more generally, and this gives fine results (in terms of balancing).

Martin