[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