[MITgcm-support] useOBCSYearlyFields

[David Wang]

Oliver,

Spot on! I changed obcs?startdate1 from 20031213 to 20040101, and found
the constant obcs transport problem went away. I was under the
impression that obcs?startdate1 has no effect when
useOBCSYearlyFields=.TRUE.; but apparently it is only the year part of
obcs?startdate1 that doesn't.

obcs?startdate1 = 20031213 was there at the first place because the
multi-year data start on the last day of 2003 so that model runs can
start at 1-Jan-2004 00:00:00.

Thanks very much,
David


On 04/16/2011 09:55 AM, Oliver Jahn wrote:
> David,
>
> one difference I notice between your setup and Martin's is that your
> startdate is December 31 while his is January first.  As I understand
> it, the year of the startdate is replaced by the year of each file when
> yearly files are used.  This might make MITgcm think that there is only
> one day's worth of data in your files (Dec 31) and it will use that for
> the whole year.  I would try using a startdate of January 1 (and thus
> have only 2004 data in the 2004 file).  If your run starts on January
> 1st as well, you'll need an extra file for the previous year.  But I
> think you already have that, right?
>
> Oliver
>
> On 2011-04-15 19:05, David Wang wrote:
>> OK, I tried a number of things including this, but all to no avail. The
>> model seems to get stuck with the first record of the obcs data and
>> never go beyond that. Since Martin doesn't have such a problem,
>> something must be wrong with my setup. But it's unclear to me where went
>> wrong... Probably stay with multi-year data for the time being.
>>
>> D.
>>
>> On 04/15/2011 10:28 AM, David Wang wrote:
>>> OK, I didn't specify tangential obcs velocity data, namely OBEv* and
>>> OBSu*, because I thought they don't count. I will test this.
>>>
>>> David
>>>
>>> On 04/15/2011 07:58 AM, Martin Losch wrote:
>>>> David,
>>>>
>>>> I have rerun my configuration with recent code, and my
>>>> obc_E/W_uVel_mean and obc_N_vVel_mean do change with time, as
>>>> expected. Here are my relevant obcs parameters (the obcs?startdate is
>>>> not used when yearlyFields = .true.):
>>>>
>>>> &OBCS_PARM01
>>>> useOBCSbalance=.FALSE.,
>>>> useOBCSYearlyFields=.TRUE.,
>>>> useOBCSprescribe=.true.,
>>>> OBCS_monSelect = 2,
>>>> OB_Iwest = 72*1,
>>>> OB_Ieast = 72*128,
>>>> OB_Jnorth = 128*72,
>>>> #
>>>> OBEtFile='ecco_theta.obce',
>>>> OBWtFile='ecco_theta.obcw',
>>>> OBNtFile='ecco_theta.obcn',
>>>> #
>>>> OBEsFile='ecco_salt.obce',
>>>> OBWsFile='ecco_salt.obcw',
>>>> OBNsFile='ecco_salt.obcn',
>>>> #
>>>> OBEuFile='ecco_uvel.obce',
>>>> OBWuFile='ecco_uvel.obcw',
>>>> OBNuFile='ecco_uvel.obcn',
>>>> #
>>>> OBEvFile='ecco_vvel.obce',
>>>> OBWvFile='ecco_vvel.obcw',
>>>> OBNvFile='ecco_vvel_corr.obcn',
>>>> #
>>>> &
>>>>
>>>> &EXF_NML_OBCS
>>>> obcsWstartdate1 = 19920101,
>>>> obcsWstartdate2 = 120000,
>>>> obcsWperiod = 86400.,
>>>> #
>>>> obcsEstartdate1 = 19920101,
>>>> obcsEstartdate2 = 120000,
>>>> obcsEperiod = 86400.,
>>>> #
>>>> obcsNstartdate1 = 19920101,
>>>> obcsNstartdate2 = 120000,
>>>> obcsNperiod = 86400.,
>>>> &
>>>> "
>>>>
>>>>
>>>>
>>>> On Apr 15, 2011, at 9:49 AM, Martin Losch wrote:
>>>>
>>>>> Hi David,
>>>>> I have a configuration where I use obcs with this option. I have
>>>>> never seen your problem, but then again, for this configuration I do
>>>>> not use latest code and so I do not have this monitor statistics yet
>>>>> (it's fairly new).
>>>>>
>>>>> Before I check, if there's anything wrong with reading the files:
>>>>>
>>>>> What about the T/S statistics?
>>>>>
>>>>> Do you have by any chance the balancing code turned on? (although
>>>>> that would not explain, why it's different for multi-year files).
>>>>>
>>>>> Martin
>>>>>
>>>>> On Apr 15, 2011, at 2:50 AM, David Wang wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I wonder if anyone has used yearly obcs files (i.e.,
>>>>>> useOBCSYearlyFields=.TRUE. in data.obcs) successfully. The obcs
>>>>>> monitor statistics (obc_E_uVel_Int, obc_S_vVel_Int) in STDOUT.????
>>>>>> show that the integrated transports across open boundaries are
>>>>>> constant in time, which is at odds with my daily time-varying obcs
>>>>>> data. I have in data.obcs
>>>>>>
>>>>>> useOBCSprescribe=.TRUE.,
>>>>>> useOBCSYearlyFields=.TRUE.,
>>>>>> OBSsFile='input/obcs/phys/OBSs_day',
>>>>>> OBStFile='input/obcs/phys/OBSt_day',
>>>>>> OBSvFile='input/obcs/phys/OBSv_day',
>>>>>> OBEsFile='input/obcs/phys/OBEs_day',
>>>>>> OBEtFile='input/obcs/phys/OBEt_day',
>>>>>> OBEuFile='input/obcs/phys/OBEu_day',
>>>>>>
>>>>>> and in data.exf
>>>>>>
>>>>>> obcsSstartdate1 = 20031231,
>>>>>> obcsSstartdate2 = 120000,
>>>>>> obcsSperiod = 86400.,
>>>>>> obcsEstartdate1 = 20031231,
>>>>>> obcsEstartdate2 = 120000,
>>>>>> obcsEperiod = 86400.,
>>>>>>
>>>>>> The obcs data files in input/obcs/phys/ take the form of
>>>>>> OB[E|S][s|t|u|v]_day_200[3|4|5]. The transport numbers become
>>>>>> time-varying and appear correct when multi-year, rather than
>>>>>> yearly, obcs data are used and useOBCSYearlyFields=.FALSE.
>>>>>> (default). I'm working with the most recent checkpoint62v.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MITgcm-support mailing list
>>>>>> MITgcm-support at mitgcm.org
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>> _______________________________________________
>>>>> MITgcm-support mailing list
>>>>> MITgcm-support at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support