[MITgcm-devel] code changes

[Martin Losch]

absolutely. I am not quite done yet, anyway.

M.

On Mar 15, 2011, at 3:54 PM, Jean-Michel Campin wrote:

> Hi Martin,
> 
> I am just checking that all the recent test went well
> and I can do a tag just after.
> Is it OK like this ?
> 
> Cheers,
> Jean-Michel
> 
> On Tue, Mar 15, 2011 at 09:05:20AM +0100, Martin Losch wrote:
>> Cool,
>> 
>> maybe we can make a tag today after the tests (Jean-Michel, could you let me know when it is a good time for this) and then I'll make these changes.
>> 
>> Martin
>> 
>> On Mar 15, 2011, at 7:07 AM, Patrick Heimbach wrote:
>> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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