[MITgcm-support] Time-varying forcing and EXF package

[Martin Losch]

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://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