[MITgcm-devel] code changes

Patrick Heimbach heimbach at MIT.EDU
Tue Mar 15 02:07:22 EDT 2011


Hi Martin,

I'm happy with the suggested changes, which as far as I can see affect
ctrl_init.F
ctrl_get_gen.F
ctrl_get_gen_rec.F or rather the routines calling this one, which,
                   in addition to ctrl_get_gen.F, are the ctrl_getobcsX.F

I'm only aware of Holly using the cyclic controls, but there may be others.
Seems to me the change should occur in conjunction with a tag,
and the change in behavior advertised on support 
(although few will likely know what you're talking about ;)

-p.

On Mar 11, 2011, at 3:47 AM, Martin Losch wrote:

> Patrick (and others who might be affected),
> 
> what do you think about this? A hypothetical comment in ctrl.h could look like this:
> 
> c     xx_${varname}period - sampling interval for the ${varname} control 
> c                           part in seconds
> c     special cases for ifdef ALLOW_CAL (in anology to pkg/exf):
> c     xx_${varname}period = -12. : control parameter is the seasonal cycle
> c     xx_${varname}period =   0. : control parameter is constant in time
> 
> currently "xx_${varname}period =   0." means seasonal cycle (inconsistent with exf), but is this used often, so that a change would break a lot of set-ups?
> 
> Martin
> 
> On Mar 10, 2011, at 11:16 AM, Martin Losch wrote:
> 
>> Hi Holly (and Patrick),
>> 
>> 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 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.
>> 
>> 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.
>> 
>> Martin
>> 
>> 
>> 
>> 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
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach





More information about the MITgcm-devel mailing list