[MITgcm-support] 'repeatPeriod' in data.exf
David Hebert
david.hebert at nrlssc.navy.mil
Tue Jun 22 10:13:19 EDT 2010
Suneet,
I have not run multi-year simulations, so I am not familiar with the
handling of leap years with cal. With repeatPeriod = 366 days, when a
year with 365 days carries over to the next year I'm wondering if the
'repeat' of the boundary file will be lagged by a day. For example, in
consecutive 365 day years, when crossing a year will January 1 using
Dec. 31st from the boundary file since there is an extra day in the
repeatPeriod?. If so, this shift in time would manifest itself greatly
over 50 years. Is there a place one can specify how many
days/hours/seconds in a model year? Again, I'm not sure but perhaps
others have more experience in this area.
David
On 06/22/10 08:58, Suneet Dwivedi wrote:
> Hi David,
>
> Thanks for your reply. This is exactly what i had in mind for
> 'repeatPeriod'.
>
> Though I am not very sure about your last question, I think a forcing
> file with 366 days will take care of both leap years (of 366 days) and
> normal years (of 365 days). But a file with lesser number of days (for
> example 365 days) will give an error for a leap year (no data on 31st
> Dec, in this case).
>
> Thanks,
> Suneet
>
> On Tue, Jun 22, 2010 at 3:45 PM, David Hebert
> <david.hebert at nrlssc.navy.mil <mailto:david.hebert at nrlssc.navy.mil>>
> wrote:
>
> Suneet,
>
> I believe repeatPeriod is the period in which the model will go
> back to the beginning of the forcing file. So if you wish to use
> the same forcing for each year (one file with 366 days according
> to your last post), I don't see why you couldn't specify
> repeatPeriod=31622400.0 in data.exf. Also, you would need to
> specify the period between records in your file in data.exf,
> &EXF_NML_02. For your case if they are daily I would think it
> would be 86400.0. Example for wind stress would be...
>
> &EXF_NML_02
> ustressfile = 'taux.bin',
> vstressfile = 'tauy.bin',
> #
> ustressstartdate1 = 20080628,
> ustressstartdate2 = 000000,
> ustressperiod = 3600.0,
> #
> vstressstartdate1 = 20080628,
> vstressstartdate2 = 000000,
> vstressperiod = 3600.0,
> &
>
> where ?stressperiod is the period between records. My case was one
> hour. Your case could be 86400.0 for one day.
>
> A question that arises (for me anyway) is how to handle leap
> years, particularly with calendar package? Does assuming 366 days
> cover this?
>
> David
>
>
>
>
> On 06/22/10 08:22, Suneet Dwivedi wrote:
>> Hi Martin,
>>
>> Thanks for your reply. Your suggestion is helpful. However, if i
>> follow what you suggested for 60 years of simulation, for
>> example, then for 8 air/sea forcing fields i will have to create
>> 480 (60*8) yearly forcing files, which is possible, but
>> cumbersome. An alternative that I could think of may be to run
>> the model for somewhat shorter duration and restart from
>> there...., for example, running the model for 15 years at a time
>> and restart from there again for 15 years and so on.....Thus
>> rather than splitting forcing fields into years, one may split
>> time window.
>>
>> I guess in this case, i should set repeatPeriod = 0 in data.exf,
>> if i am using continuous in time daily forcing fields for 15
>> years. But I am not sure how to set namelist parameters in
>> input/data while restarting from pickup files. What i could
>> gather from looking at verification directory examples and mitgcm
>> manual is that it is possible to restart the model from pickup
>> files by setting nIter0 equal to number as suffix in pickup file,
>> but i am not sure how to set data.cal in this case. Probably, I
>> should not include data.cal in my input directory when I am
>> restarting. Is this right? Any suggestions....
>>
>> Thanks again,
>> Suneet
>>
>> On Tue, Jun 22, 2010 at 8:19 AM, Martin Losch
>> <Martin.Losch at awi.de <mailto:Martin.Losch at awi.de>> wrote:
>>
>> Suneet,
>>
>> you can split you forcing fields into years. They have to
>> follow this naming convention:
>> forcingFile_year, where "year" is a 2 or 4-digit year (e.g.
>> myatemp_1996, myatemp_1997, etc).
>>
>> In data.exf set:
>> useExfYearlyFields= .TRUE.,
>> twoDigitYear = .FALSE.,
>>
>> and
>> atempfile = myatemp,
>> etc. If you want to use a Gregorian calendar the data.cal
>> should look like this:
>> &CAL_NML
>> TheCalendar='gregorian',
>> # here you insert your start date, of course
>> startDate_1=19920101,
>> startDate_2=000000,
>> # this makes the model interpret output "freqs" (e.g.
>> dumpFreq) close to 1 month (say 2592000.) as a "real" month,
>> the same for a year.
>> calendarDumps = .TRUE.,
>> &
>>
>> There are a few examples in the MITgcm_contrib area (arctic,
>> high_res_cube)
>>
>> Martin
>>
>>
>> On Jun 22, 2010, at 1:38 AM, Suneet Dwivedi wrote:
>>
>> > Hi Everybody,
>> >
>> > Could anyone of you please tell me what is the exact
>> meaning of parameter 'repeatPeriod' in exf package/data.exf?
>> >
>> > I wish to perform a long run of 50-55 years with daily
>> air/sea forcing values over Indian Ocean. Matlab is unable to
>> store and process such a long matrix of dimension [250 150
>> 20000] ~ O(1e+10) with 64 bit precision. An alternative way
>> to do this may be to use climatological daily forcing values
>> (averaged over all available years) of dimension [250 150
>> 366] and use the climatological values for each year of
>> simulation. In this case, i need to know the variable that
>> does this in MITgcm. I wonder 'repeatPeriod' does this. Am I
>> right? For example, if i set 'repeatPeriod' to something like
>> 31622400.0 (for 1 year), will I be able to use same values of
>> forcing on same days of each year after completing one year
>> of simulation? Please suggest.
>> >
>> > Thanks,
>> > Suneet
>> >
>> > _______________________________________________
>> > MITgcm-support mailing list
>> > MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20100622/42778d57/attachment-0001.htm>
More information about the MITgcm-support
mailing list