[MITgcm-support] Monthly averaged OBCS with useOBCSYearlyFields

[Naughten, Kaitlin A.]

Thank you very much Martin. A constant period of 2629800 seems to do the job!
All the best,
Kaitlin


Dr Kaitlin Naughten | Ocean-Ice Modeller | British Antarctic Survey

High Cross, Madingley Road, Cambridge CB3 0ET

Email: kaight at bas.ac.uk<mailto:kaight at bas.ac.uk>

________________________________
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org> on behalf of Martin Losch <Martin.Losch at awi.de>
Sent: 25 October 2019 12:28
To: MITgcm Support <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] Monthly averaged OBCS with useOBCSYearlyFields

Forgot about your option 2: This does not work with yearly fields, i.e. the period = -12. always assumes a climatological year with 12 records that does not change with year. Hence the model expects the correct filename and does not add the year, i.e. if you data.obcs says “UVEL_piControl.OBCS_N” together with *period=-12, then the model looks for a file with this name (“UVEL_piControl.OBCS_N”), but not “UVEL_piControl.OBCS_N_1979”

Martin


> On 25. Oct 2019, at 13:23, Martin Losch <Martin.Losch at awi.de> wrote:
>
> Hi Kaitlin,
>
> as far as I know the calendarDumps option in data.cal on refers to the “dumps”, so the output of the model. For the input, this functionality is not implemented, not even for the exf pack. (I am assuming here, that you do use pkg/exf)
>
> That means to the *Period will always be interpreted as such, i.e. your 30days, will lead to reading new obcs fields (or exf fields) every 30 days, which will lead to a phase error and lack of data at the end (the record determination happens in S/R  EXF_GetFFieldRec, which is the same for obcs and exf.
> With a Gregorian calendar, I normally compute the perod as
>
> 0.25*(366 + 3*365)*86400/12 = 2629800.
>
> Obviously, this will only work with a regular cycle of leap years. If you want to be more accurate, you’ll have to divide the entire length of your run (in seconds) by the total number of months of your simulation. This will lead to a small inaccuracy in loading forcing data for a specific month, but there will be no phase error per year.
>
> Martin
>
>
>> On 25. Oct 2019, at 13:04, Christoph Voelker <christoph.voelker at awi.de> wrote:
>>
>> Dear Kaitlin,
>> I think your first method should work, BUT you need to provide also the monthly fields for the adjacent years, so the model has something to interpolate. In your case, was there a file UVEL_piControl.OBCS_N_1980 present?
>> Best regards, Christoph
>>
>> Am 25.10.19 um 11:37 schrieb Naughten, Kaitlin A.:
>>> Hi everyone,
>>>
>>> I am trying to run with monthly-averaged OBCS which change every year (useOBCSYearlyFields=true) and a Gregorian calendar meaning the months are different lengths. I am not sure that the code allows me to do this. I have tried two different things:
>>>      • Set obcs*period to 2592000 (30 days) and hope that the code turns it into a "real" month, as it does for the diagnostics. This doesn't seem to work as the model dies near the end of the first year when wants a 13th record to interpolate to, and can't find it.
>>>      • Set obcs*period to -12 as you do for a repeating monthly climatology. Now the code dies because it's constructing a weird file name which doesn't exist (seems to be either UVEL_piControl.OBCS_N or UVEL_piControl.OBCS_N.001.001.data when it should just be UVEL_piControl.OBCS_N_1979). Looking through the code in obcs_exf_load, it seems that obcs*period=-12 isn't set up to work with useOBCSYearlyFields, because the variables year0 and year1 are never initialised.
>>> What do you suggest I do? Is there a way to set a non-constant OBCS period so the months can be different lengths? Or, an easy way to add this functionality to the code?
>>>
>>> Many thanks,
>>> Kaitlin Naughten
>>>
>>> Dr Kaitlin Naughten | Ocean-Ice Modeller | British Antarctic Survey
>>> High Cross, Madingley Road, Cambridge CB3 0ET
>>> Email: kaight at bas.ac.uk
>>>
>>>
>>> This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system.
>>> UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
>>> Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.
>>>
>>>
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>>
>>> MITgcm-support at mitgcm.org
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>> --
>> Christoph Voelker
>> Alfred Wegener Institute
>> Helmholtz Centre for Polar and Marine Research
>> Am Handelshafen 12
>> 27570 Bremerhaven, Germany
>> e:
>> Christoph.Voelker at awi.de
>>
>> t: +49 471 4831 1848
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org
http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20191028/6cffff95/attachment-0001.html>