[MITgcm-devel] code changes

[Holly Dail]

Hello -

> maybe better to continue this on the devel-list. 
> 
> I had another look into the ctrl-pkg. Your code below is basically a modified copy from ctrl_get_gen.F, right? This in turn looks similar to exf_set_gen.F

Yes, its definitely a copy.

> except that there the -12 is implemented and the 0 is dealt with in exf_getffieldrec.F. In the current code I have copied the handling of fldperiod=0 from exf_getffieldrec to ctrl_get_gen_rec and this will have no effect on the surface forcing ctrl fields because in ctrl_get_gen 0 is interpreted as monthly values and ctrl_get_gen_rec is not called.

Oh okay -- I didn't catch that. 

> I suggest to change this behavior like this:
> 1. in ctrl_get_gen replace (xx_genperiod .EQ. 0) with (xx_genperiod .EQ. -12) to be consistent with exf_set_gen. This might affect a few set-ups and we have to be careful to communicate this change (how would we do this? support list?). The alternative is to use a different number for constant fields, e.g. -1, but that would be inconsistent with exf
> 2. add your code to ctrl_getobcs?.F but also replace 0 by -12
> 
> The second point is independent of the first one, but I find it strange to have different parameters behave differently (e.g., xx_obcswperiod and xx_atempperiod). 
> 
> In both cases ctrl_init.F also needs to be modified (the change from fldperiod 0 -> -12, and still catching the 0), so
>>        if ( xx_atempperiod .EQ. 0 ) then
>>        startrec=1
>>        endrec=12
>>        else
> has to become
>>        if ( xx_atempperiod .EQ. -12 ) then
>>        startrec=1
>>        endrec=12
>>        elseif ( xx_atempperiod .EQ. 0 ) then
> 
>>        startrec=1
>>        endrec=1
>>        else
> or so. But this is exactly the part of the ctrl-package, where I quickly loose the overview and I need Patrick's opinion.

Your suggestions look appropriate to me.

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.

Given the default period of 0 set in ctrl_readparms.F, if 0 is mapped to mean controls then mean controls becomes the default, which makes sense to me.

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?  

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.

Thanks -
Holly



> On Mar 9, 2011, at 8:32 PM, Holly Dail wrote:
> 
>> [...] thought I'd ask a separate question re. your changes.
>> 
>> For ctrl period = 0, your changes in ctrl_get_gen_rec.F assume that a period = 0 indicates a single mean control field right?  For atmospheric controls, I believe the rest of the code is all set up to assume a period = 0 implies repeated monthly controls (see ctrl_get_gen.F for an example).  I have used the code this way for a long time for my atmospheric controls and it seems to work great for me.  Of course, for parity with exf it should really be that period = -12 maps to repeated monthly controls, in which case period = 0 mapping to a mean control field would be a perfect idea.  I would use both repeated monthly controls and annual mean controls regularly if available.
>> 
>> For OBCS controls, the current code base (before your changes) doesn't do repeated monthly controls if one sets period = 0.  I have a very simple fix for the 4 ctrl_getobcs?.F files tested if you want to check it in (I've only tested the ctrl_getobcss.F).  I'll append it below ... this code snippet replaces the single call to ctrl_get_gen_rec that is in these S/R now.  Of course this will probably only work properly if you decide to reverse your changes in ctrl_get_gen_rec.F (or to change it all to -12 for repeated controls).
>> 
>> Thanks -
>> Holly
>> 
>> 
>> # ifdef ALLOW_CAL
>>        if ( xx_obcssperiod .EQ. 0 ) then
>> c     record numbers are assumed 1 to 12 corresponding to
>> c     Jan. through Dec.
>>           call cal_GetMonthsRec(
>>    O           obcssfac, obcssfirst, obcsschanged,
>>    O           obcsscount0, obcsscount1,
>>    I           mytime, myiter, mythid
>>    &           )
>>        else
>> c--   Get the counters, flags, and the interpolation factor.
>>     call ctrl_get_gen_rec(
>>    I                   xx_obcssstartdate, xx_obcssperiod,
>>    O                   obcssfac, obcssfirst, obcsschanged,
>>    O                   obcsscount0,obcsscount1,
>>    I                   mytime, myiter, mythid )
>>       endif
>> # else
>> c--   Get the counters, flags, and the interpolation factor.
>>     call ctrl_get_gen_rec(
>>    I                   xx_obcssstartdate, xx_obcssperiod,
>>    O                   obcssfac, obcssfirst, obcsschanged,
>>    O                   obcsscount0,obcsscount1,
>>    I                   mytime, myiter, mythid )
>> # endif
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel