[MITgcm-support] {Disarmed} Re: Re: MITgcm-support Digest, Vol 247, Issue 3

Thu Jan 18 11:06:00 EST 2024

Hi again Martin,

Really sorry, I've hit a problem again. I hope I am clear in my explanation and please just let me know if not.

I've taken your suggestion of having all the forcing in one long T_air.bin file (expecting that with the correct values in data.cal's "startDate_1" and data.exf's "atempstartdate1", the model can figure out where to correctly begin reading the forcing from). However, in a little test of this, I've produced an odd error.

Read on below for the details of that, but I'll cut to the chase of what I think the problem is - could the issue be that my data.cal "TheCalendar" is set to "model" which represents a 360-day year, but I've been handling my iteration-numbers, pickup files, nIter0 etc. assuming a 365-day year? I did this because I started my study based on a previous study's work and model configuration. Their pickup files' iteration numbers made sense and corresponded to 250-year intervals when assuming a 365-day year (e.g., iter# * deltaT /60/60/24/365 gave pickup files at years 25000, 25250, 25500, 25750, etc.) but gave odd decimal-year values assuming a 360-day year. So, I carried on from their work and ran an additional ~10,000 years of model time (working under the 365day assumption) to re-stabilise the model on my machine and now I'm beginning new experiments at model yr39500 (assuming a 365day year). I think I'm therefore having trouble with the time-varying forcing because of this 365day-vs-360day issue introduced by turning on the data.cal package and using "TheCalendar = 'model' ".

Please read on (if it helps) to see how my test below led me to this conclusion, otherwise I'd appreciate any advice as to how to make this jump from 365-day iteration-numbers in my spin-up simulations to now experiments that need to be run on a 360day year. [E.g. I start from iteration number 86505000, which corresponds to a decimal year 40048.611 in this new 360day framework, which is odd and I don't know how to resolve. Perhaps I need to run another ~0.399 of a year of spin-up to get to an iteration number that corresponds to a whole-number year in this new 360d framework? But I'm confused - does all my spin-up output to date (before this time-varying forcing work) truly represent 39500 years of total model run time or is it actually 40048.6111? (Note that my deltaT is 14400 sec.)]

My test was to make an 18-year-long "T_air.bin" forcing file and to run three separate 6-year-long simulations, to see whether the model would pick up from the correct place in T_air.bin each time. Below are my settings:

data
--> nIter0 = 86505000        (the last pickup file from my spin-up, represents year 39500 (iter86505000 * 14400sec (my deltaT) / 60/60/24/365 = yr39500 (although perhaps this use of 365days is wrong. Represents year 40048.61111... in 360d framework.)
--> nTimeSteps = 13140    ( = 6 years. 13140 steps *14400sec (deltaT) /60/60/24/365 = 18 years. Again perhaps 365days is wrong.)

data.cal
--> startDate_1 = 00010101 (for nIter0==0)

data.exf
--> atempperiod = 31536000 (1 year in 365d framework)
--> atempstartdate1 = 395000101 <-- !! This gives error "Tried to read non-existent record (543)". Changing atempperiod to 31104000 (1yr in 360d framework) gives "Tried to read non-existent record (550)". And note, 550 and 543 are close to the offset between nIter0=86505000 converted to years using 365d (39500yrs) vs 360d (40048.611) (diff = 548.6111). I therefore changed atempstartdate1 to = 400480101 as a test and the simulation ran without errors. (Though note, 40048.611 does not == 400480101. **Perhaps I need to run my spin-up another 0.3999 of a year longer to get to an iteration number that corresponds to whole-number year under the new 360d framework?)

Best,
Maddie

________________________________
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org> on behalf of mitgcm-support-request at mitgcm.org <mitgcm-support-request at mitgcm.org>
Sent: Wednesday, January 10, 2024 5:00 PM
To: mitgcm-support at mitgcm.org <mitgcm-support at mitgcm.org>
Subject: MITgcm-support Digest, Vol 247, Issue 3

Send MITgcm-support mailing list submissions to
        mitgcm-support at mitgcm.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.mitgcm.org%2Fmailman%2Flistinfo%2Fmitgcm-support&data=05%7C02%7Cmgs23%40st-andrews.ac.uk%7C9dfd3518ce0e4493fdc208dc11fda29d%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638405029262699358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C62000%7C%7C%7C&sdata=iF1gXMdqY5yBRVFrS5Qb4dVRd2K8Yzt2vW03batcPGQ%3D&reserved=0<http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support>
or, via email, send a message with subject or body 'help' to
        mitgcm-support-request at mitgcm.org

You can reach the person managing the list at
        mitgcm-support-owner at mitgcm.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MITgcm-support digest..."

Today's Topics:

   1. Re: Time-varying forcing and EXF package (Martin Losch)

----------------------------------------------------------------------

Message: 1
Date: Wed, 10 Jan 2024 10:31:40 +0100
From: Martin Losch <Martin.Losch at awi.de>
To: MITgcm Support <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] Time-varying forcing and EXF package
Message-ID: <19D56223-1E94-42AF-833F-45CFBFA93AD1 at awi.de>
Content-Type: text/plain; charset="utf-8"

Hi Madison,

see anwers below:

> On 10. Jan 2024, at 01:15, Madison Shankle <mgs23 at st-andrews.ac.uk> wrote:
>
> Hi Martin,
>
> Thank you so much; that's clarified a lot of things for me. Can I ask a few follow-up questions? 3 small clarifying ones, and 1 further advice one (much appreciated).
>
> (1) I misunderstood that data.cal's "startDate1" corresponded to nIter0=0, instead of just nIter0. Can I just check that that's correct? See the documentation that says: "Note that the first record read and used by the EXF package corresponds to the value ?startDate1? set in data.cal." (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmitgcm.readthedocs.io%2Fen%2Flatest%2Fphys_pkgs%2Fexf.html%23compile-time-options&data=05%7C02%7Cmgs23%40st-andrews.ac.uk%7C9dfd3518ce0e4493fdc208dc11fda29d%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638405029262699358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C62000%7C%7C%7C&sdata=PMiwJQTX5KNMYTyh%2FZa9w4FgDwfZFnjUfXu2M%2FveGGg%3D&reserved=0<https://mitgcm.readthedocs.io/en/latest/phys_pkgs/exf.html#compile-time-options>)

Yes taht?s correct and I think that this statement is misleading and should be changed. If you have a good suggestion (based on your experience) for this paragraph, please feel free to contribute a pull request, and we can work on this together.

>
> (2) I also missed that MITgcm interpolated between records provided in T_air.bin! Would that maybe explain why I was getting an error "lib-4016 : UNRECOVERABLE library error.   A READ operation tried to read a nonexistent record (1002)." in a 1000yr long run? (However, my T_air.bin file in that case was 1001 records long, so I'm still not sure what the problem is.
I am not sure, what causes this. ?in theory?, it should have worked.

>
> (3) Also didn't know about "repeatPeriod" in &EXF_NML_01 of data.exf - thank you!! This will likely do exactly what I want to do. So if I set this to 31104000000.0 (1000yr in seconds) and set atempperiod = 31104000.0 (360 days in seconds) and have all other exf periods set as 0, does MITgcm know that that repeatPeriod parameter should only be applied to T_air.bin and won't throw an error? (And in this scenario, the T_air input file doesn't need an additional entry like you mentioned, correct?)

Yes, that should work ( "repeatPeriod? can be found in the admittedly sparse documentation (o: ).

>
> (4) Do you have any advice for running a simulation with time-varying T_air whose period is greater than 1000yr, given that I run simulations that last 1000 years, one after another, continuing on from pickup files. Say I want T_air with a periodicity of 10,000yr. And my simulation will be something like 20 or 40,000 years in total. I could make 10 separate T_air files to represent years 1-1000, 1001-2000, 2001-3000, and so on to 10,000 when the temp reaches its starting point again, and then just be very careful to just use the correct T_air file with each simulation. But there must be an easier way than this? (However your method of making use of the "repeatPeriod" parameter seems perfect for my experiments where T_air varies with periods of 500yr and 1000yr.)
pkg/exf was not really written with these long periods in mind. If possible, I would have all forcing in one file T_air, and then the model should be able to figure out, which record to read when with the correct startdate in data.cal and the correct atemp_startdate* in data.exf. The start dates should not be changed during the integration and restarts.
If a single T_air.bin is too big, you?d have to do it as you implied, being very careful, which file to use when (and modify the atemp_startdate* in data.exf accordingly. That sounds like a recipe for failure ?
The model can deal with yearly fields (one file per year, say T_air.bin_2035, etc.) but this only works for years up to 9999, I guess. You?d have to modify the code to accomodate your long runs.

Martin

------------------------------

Subject: Digest Footer

_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.mitgcm.org%2Fmailman%2Flistinfo%2Fmitgcm-support&data=05%7C02%7Cmgs23%40st-andrews.ac.uk%7C9dfd3518ce0e4493fdc208dc11fda29d%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638405029262699358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C62000%7C%7C%7C&sdata=iF1gXMdqY5yBRVFrS5Qb4dVRd2K8Yzt2vW03batcPGQ%3D&reserved=0<http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support>

------------------------------

End of MITgcm-support Digest, Vol 247, Issue 3
**********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20240118/3180abf2/attachment-0001.html>