DATM & DROF xml config

[anton-seaice]

Following on from #20 , two changes are proposed:

• In IAF configurations, for datm and drof, set taxmode to limit (doco: here). This means that if the model date is set outside the range of provided forcing data, the date would be rejected. (Currently it is cycled around when outside the range). (https://escomp.github.io/CDEPS/versions/master/html/streams.html#definitions-of-each-keys-used-in-stream-definition-file)
• In RYF configurations, set year_first, year_last and year_align to be 1990 to be consistent with the input file. As data cycles around in the current setting, this does not make any functional change, but may be easier to interpret for future users. (The model year is set in the nuopc.runconfig, and we would leave it set to year 0 to be clear its not a real year).

[dougiesquire]

In RYF configurations, set year_first, year_last and year_align to be 1990

I think year_first and year_last need to remain at 1900, as the time variable in the files has been reset to span 1900 even though the data is from 1990-1991. But we could change year_align to 1900 so they are all consistent.

[aekiss]

I think it's quite a good safety feature to have taxmode=limit to avoid users inadvertently getting into leap-year tangles like these (which are much worse with a forcing cycle not divisible by 4).

[anton-seaice]

I think ill take that as consensus :)

Actions:

• generate_xml_datm.py could be edited to change the comments re: year_align
• generate_xml_datm.py change taxmode to 'limit'
• generate new datm.streams.xml for IAF with taxmode='limit'
• change datm.streams.xml for RYF, to set year_align=1900
• repeat for drof

[anton-seaice]

From @aekiss on slack:

We used 1900 in OM2 so I think we might as well stick with that. The first 4 mo of RYF9091 is from 1991 anyway.
Don't use 0000, since this may cause problems if any components use a strict definition of the Gregorian calendar as applying only from 15 October 1582 onwards, with a Julian calendar prior to that. COSIMA/access-om2#117

So I think we also change the start year in nuopc.runconfig to 1900

[aekiss]

FYI re. #28, JRA55-do v1.5.0 runs to 15Jul2020, and v1.5.0.1 extends this to the end of 2023 https://climate.mri-jma.go.jp/pub/ocean/JRA55-do/ so experiments with these forcings will want a later ending date.

[anton-seaice]

FYI re. #28, JRA55-do v1.5.0 runs to 15Jul2020, and v1.5.0.1 extends this to the end of 2023 https://climate.mri-jma.go.jp/pub/ocean/JRA55-do/ so experiments with these forcings will want a later ending date.

Sounds like a seperate change to add these years? Do you want to do this now too?

[anton-seaice]

There is code in the python scripts to handle RYF (e.g. https://github.com/COSIMA/MOM6-CICE6/blob/51d97ab5a5ceafbb75fd0e519ab89458654e1ef5/generate_xml_datm.py#L96) but the python scripts are not in the RYF branch. Is this intentional? Did we decide not to use the script for RYF, or should the script be in both branches?

[dougiesquire]

There is code in the python scripts to handle RYF (e.g. https://github.com/COSIMA/MOM6-CICE6/blob/51d97ab5a5ceafbb75fd0e519ab89458654e1ef5/generate_xml_datm.py#L96) but the python scripts are not in the RYF branch. Is this intentional? Did we decide not to use the script for RYF, or should the script be in both branches?

We should move the script (and others) into a separate repo(s). @micaeljtoliveira mentioned he has some "om3 tools" in a repo somewhere. Perhaps we should get this into the COSIMA org and consolidate there.

[anton-seaice]

We should move the script (and others) into a separate repo(s). @micaeljtoliveira mentioned he has some "om3 tools" in a repo somewhere. Perhaps we should get this into the COSIMA org and consolidate there.

I created #29 :)

[anton-seaice]

Closed by #26 and #28