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

[Martin Losch]

Hi Madison,

startDate_1/2 ind data.cal specify the point in time to which nIter0=0 refers (interally this is called baseTime), so with your data.cal, your year has 360days (TheCalendar=‘model’), where nIter0=0 refers to Jan01,39500,0:00 (assuming that startdate_2=000000). Alternatively you could set the startDate to 00010101 and for your pickup in year 39500 use an nIter0 that corresponds to this year, ie. 39500/deltaTclock

All constant-in-time forcing fields need to have a “period” of 0. (e.g. “uwindperiod=0.”). I am not sure if you need a startDate for those, but it wouldn’t hurt.
For your time varying forcing your setting says (again assuming atempstartdate2=000000), that the first record in the forcing file T_air.bin is on Jan01,39500,0:00, the second on Jan01,39501,0:00, etc, and the model interpolates bi-linearily between them. I don’t know about the details of your experiment, but you may want to shift this start time to the middle of the year (and then you’d need an additional record for year0-1 for the bilinear interpolation, but see below for an easy way out).

You can also set a repeat period, e.g. for your 1000 y file:

 repeatPeriod = 31104000000.0, ( 86400*360*1000 )

in &EXF_NML_01 to make the model start again with the first record, if it goes beyond 1000ys. So in the “scenario” where your nIter0=39500/deltaTclock, you could use atempstartdate1=00010101 with repeatPeriod = 31104000000.0,

If your cycle is only 500y, then you could get away with a shorter forcing file and a repeatPeriod of 500y.

Hope that helps,

Martin

> On 30. Dec 2023, at 20:15, Madison Shankle <mgs23 at st-andrews.ac.uk> wrote:
> 
> Dear all,
> 
> Seeking help setting up time-varying forcing. I unfortunately can't submit jobs at the moment, so apologies for not doing more troubleshooting on my own, but at present it would be very helpful to just have my understanding of a few key parameters checked.
> 
> Background: I have a time-varying T_air.bin forcing file (dimensions nTime, nY, nX = 1000, 140, 72) where the time dimension consists of annual air temp profiles (so the entire file represents a 1000yr-long record, that varies in time). All other forcing files are kept constant. T_air varies cyclically with a periodicity of 500yr, so two cycles are contained in T_air.bin. (I made the file 1000yrs long as I typically run my simulations for 1000yrs at a time, which takes about 24hr, and I can start the next simulation the next day.)
> 
> Is my understanding of the following  parameters correct, and are there any other parameters to be changed that I have missed out?
> 
> data.exf
> --> atempstartdate1 = 395000101
> --> atempperiod = 31104000
> Here "atempstartdate1" specifies that I have read in a T_air.bin file whose record starts on Jan 1, year 39500. (I am starting my simulations off of a previous study's output, which ran ~32000yr, from which it then took an additional ~7000yr to spin-up my simulations on ARCHER2 with some slight edits to the model configuration. So, with my model configuration properly spun up, I'm now ready to start the experimental (time-varying temp) simulation at year 39500). 
> 
> data.cal 
> --> TheCalendar = 'model'
> --> startDate1 = 395000101
> Here "startDate1" tells the model which record to read first from T_air.bin. At this point, I can say that my 1000yr-long T_air record starts at 395000 (in data.exf) and this parameter tells the model to start reading from that first time step. So, I was planning on just updating these two parameters each time I start a new 1000yr-long run (e.g. to 40500, 41500, 42500, etc. each time I start a new run). However, I suppose I could also simply write a 40,000yr-long T_air file (40000,ny,nx) (as my goal is to run my simulation this long), in which case I could leave atempstartdate1 as 395000101, and only have to update data.cal's startDate1 parameter with each new model run.
> 
> 
> Is that all correct and am I missing anything else that would need to be changed to set up a time-varying run? Apologies again; I nearly got this working before the holidays but as I said can't submit jobs at the moment, so making some progress by getting feedback from this group while I sort that out would be very appreciated.
> 
> Thanks and best wishes for the new year,
> M. Shankle
> 
> 
> 
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support