IAF vs RYF configurations

[ashjbarnes]

The way it's been written so far, I've mostly had RYF in mind. If the end user wanted IAF, they should be able to pass an IAF = True flag to ensure that the time encoding doesn't include the 'modulo' attribute, which tells MOM6 to wrap forcing around each year

To handle this though we'll need to think about how to structure our input files. Will they still be separated yearly to keep sizes down? If so I think we'll need to 'pad' the files with forcing from adjacent years as @reillyja was explaining to me this afternoon

There are probably some other things that would need to be considered to make IAF runs easy to set up out of the box. I don't have much experience with IAF in MOM6 though so don't know what these would be

[navidcy]

Where is the RYF/IAF prescribed? Is RYF/IAF something general or something only used for the JRE55 reanalysis?

[reillyja]

I've been working on this the past few days. As a test, I cut out 5 years (1970-01-01 --> 1974-12-31) of the ACCESS-OM2-01 JRA55 version 1.5 experiment. For the atmospheric forcing, as a first try, I pulled the YEAR 1 (1970) reanalysis files and stored these under the inputdir/jra_forcing and updated the data_table with the relevant file names and paths.

Trying to run this with the calendar = 'GREGORIAN' specified in input.nml, I get an error stating FATAL from PE ... ERROR in coupler_init: Illegal calendar type.

The reanalysis files are gregorian which doesn't match the way the obc files are saved (julian). I recall @ashjbarnes had some issues saving the obc files as gregorian? Any thoughts on how to fix this?

[ashjbarnes]

The executable that you're probably running is using an FMS version from like 2018. I think they've subsequently added a 'gregorian' calendar. In the meantime though just switch 'gregorian' to 'julian' and that'll work fine for all dates post 1901

[ashjbarnes]

Hopefully just adding jullian in input.nml does the trick?

[reillyja]

Ah I didn't realise that about the FMS version, thanks.

I tried with JULIAN calendar, and get this error:
FATAL from PE 0: time_interp_external 2: time 719177 (19700101.010000 is before range of list 719177-719541(19700101.013000 - 19701231.223000),file=./INPUT/jra_forcing/rlds_input4MIPs_atmosphericState_OMIP_MRI-JRA55-do-1-5-0_gr_197001010000-197012312100.nc,field=rlds
So I've been trying to figure out why this specific forcing file is triggering an error now. I'm not sure how it gets the "range of list" but if I can change that to match up with the starting time (19700101.010000) then I imagine this'll work.

[ashjbarnes]

Could you please link the run directory? I'll have a look!

[reillyja]

Here's the rundir: /home/581/jr5971/mom6_rundirs/sharkbay_iaf

Hopefully you can open the input directory from that, otherwise the inputdir is "/scratch/v45/jr5971/mom6_regional_configs/sharkbay_iaf"

Let me know if you can't access anything!

[ashjbarnes]

permission denied to rundir yeah

[reillyja]

How did we do this again? Should I just move the rundirectory to a scratch location?

Just a minute though - I'm just going to test this roundabout way first where I'm just shifting all time values back by 1.5 hours. This matches up with the times in other forcing files so it should potentially work. It's a bit of a fudge method though so not sure if it's really valid

[ashjbarnes]

Looks like you've downloaded a fresh set of JRA -55 forcing right? Nice! I haven't used it before

This version is on the gregorian calendar. Further, since it starts from Jan 1900, it'll have Feb 1900 as a non leap year where julian will

That means that you're one day out, and the JRA-55 data you've selected falls outside the range that input.nml is expecting

[ashjbarnes]

Confusingly it looks like your JRA NETCDFs are being read correctly (since it's using the gregorian calendar as expected) but mom6 refuses to accept gregorian in the input.nml.

A fix would be to re-encode the JRA forcing data onto the julian calendar OR change the index date to days since 1950, and subtract the corresponding number of integer days from your time dimension

What I did with my era5 forcing data was reset the calendar to be 'hours since whenever-my-experiment-starts'. You can see my code at the end of the demo notebook. Keep in mind though that your data appears to be in days with decimals representing smaller times whereas mine is integer hours

[ashjbarnes]

EDIT:

Sorry John no you're right it's only out be a few hours not a whole day so this can't be it. Looking at your forcing files though the JRA inputs also begin at an integer day, so I'm not sure why it thinks you're starting a fraction of a day through?

[reillyja]

I think I've fixed that issue by shifting the times back by 1.5 hours to get all the times matched up. I'm now getting an error with the forcing files related to the "modulo" attribute.
FATAL from PE 0: time_interp_external 2: period of list exceeds modulo period,file=INPUT/forcing/forcing_obc_segment_001.nc,field=u_segment_001
Hoping that just removing this attribute from the time coordinate will solve this without having to look further into the root cause haha

[reillyja]

Success! it runs :) It takes less than a minute to run 5 days. I'll run it out to December whilst figuring out how we are going to start automating the transition between forcing files.

[reillyja]

There's still some underlying issues that I'll look into regarding the FMS version not accepting the "GREGORIAN" calendar, and I can have a go at setting up the IAF/RYF flag in the regional_library too.

[ashjbarnes]

If you want to try a more recent executable here's one with up to date FMS as of earlier this year:

/g/data/v45/ab8992/mom_executables/forjohn_newfms

EDIT:
On second thought this changes a couple of other (stupid) things that I had to fix with the regional library. Lmk if you want to try this exe and I'll point you to a version of regional_library that works. I basically just had to remove the 'time' dimension from initial condition fields and it worked again

[reillyja]

I think I've fixed that issue by shifting the times back by 1.5 hours to get all the times matched up. I'm now getting an error with the forcing files related to the "modulo" attribute. FATAL from PE 0: time_interp_external 2: period of list exceeds modulo period,file=INPUT/forcing/forcing_obc_segment_001.nc,field=u_segment_001 Hoping that just removing this attribute from the time coordinate will solve this without having to look further into the root cause haha

Just realised that my "fudge" fix for the time errors I was getting above was completely wrong. Different variables in the JRA forcing dataset (e.g., "psl", "tas" etc.) are saved at different times of the day (e.g., 00:00:00, or 12:00:00, or 01:30:00). The error above was hit trying to interpolate those times back to the start date (00:00:00), but as these were the first time entries, there was nothing before the start date to interpolate between (and extrapolation is not possible i guess). Hence why we need to "pad" the files as mentioned in the first post on this issue for IAF. This simply sticks the last timestep of the previous year, and the first timestep of the next year to the file which has fixed my error. I used the script from this repo for this: https://github.com/raphaeldussin/pad_forcing/tree/main

Also, I think the manual fix I previously attempted, which shifted the offset times back to 00:00:00 might be contributing to the errors I mentioned in this hive-post related the "eta has dropped below bathyT" problem, but I haven't confirmed that just yet.