I am looking to run ACCESS-OM2 at 1deg resolution using surface forcings from ESM1.5 future projection runs (SSP585). I have been able to obtain 3 hourly atmospheric data from @tiloz (thank you!) and want to impose that as a surface forcing like how JRA55-do is used as an input to the YATM of the ACCESS-OM2 config. (There should also be a spinup, and data for the historical period exists in 1day resolution to my knowledge.)
The resolutions between JRA55-do and ESM1.5 are different, but I am not sure where the documentation is to sort this out so that I can force the 1 deg ocean model correctly (I got stuck at here). As I want to use ESM data as the forcing, my understanding is that I should be using the YATM in ACCESS-OM2 rather than straight away running a flux-forced simulation with MOM5 like Dhruv et al. here.
Any pointers/comments/help would be greatly appreciated!
Cheers,
Ellie
Hello Ellie,
Thanks for your post, this ability would be great. Just letting you know we’ve noted this post. While it’s been discussed, we don’t have it properly figured out and documented, so I will mark this outofscope for now. Though hoping the community can help out here. This might also be somewhat related to this: Easy forcing perturbation experiments in ACCESS-OM2 + Tutorial
I am looking to run ACCESS-OM2 at 1deg resolution using surface forcings from ESM1.5 future projection runs (SSP585)
Interesting to hear your plans. Following @Flick.Chun post, this sort of thing falls under a science application so is out of scope for ACCESS-NRI support. For additional background, I suggest having a look at Ryan’s tutorial and we wondered if @dkhutch@wghuneke might have done related things? Having said this, we’ve had a little a chat (@AndyHoggANU@anton@Aidan@spencerwong) around a suggested workflow:
Suggest using bulk formula not a flux forcing for ACCESS-OM2 forcing (avoids tricky sea ice issues for example).
Obtain or re-run ESM1.5 with the variables and temporal resolution required to match ACCESS-OM2’s bulk formula inputs. This post can likely help. It’s very likely that outputs from existing runs won’t be appropriate for this but @spencerwong thought (without checking) it was possible. Take care to match the height and other constraints (MOM5 unlike NEMO can’t adjust on the fly). To reduce the forcing size, you may also want to consider reducing the frequency of temporal output, at least for some variables but you’ll have to check the model can support interpolation in that regard (NEMO can).
A remaining issue is the different grids/resolution. ACCESS OM2 can re-grid on the fly but you need an appropriate weights file (calculated offline once), you may be able to find one in the CM2 configuration but this presumes that they use the same grid so one needs to check that first or re-create the file (see Changing the OASIS remapping fileshere, i.e., To remake the mapping files using the new land-sea masks use the script make_remap_weights.py in the access-om2/tools/ directory of the main access-om2 repository. ).
Looking forward:
we’d love to see this kind of workflow documented – it’s very likely other COSIMA users would like to do this kind of thing. For example, feel free to share your progress on the ACCESS OM2 configuration docs or at the training program.
We have a planned training session on doing perturbations with ACCESS-OM2 led by @aekisscoming up too.
Hi @ongqingyee,
I haven’t been down this road. But it seems like you’ve got two major tasks here:
Convert resolution from the existing JRA fields to the UM7.3 grid diagnostics.
Mimic the forcing fields that currently go into YATM for ACCESS-OM2 using ACCESS-ESM equivalents.
I have examples of re-generating the remapping weights for ACCESS-ESM1.5 paleo runs, for example in this repository see the steps in make_coupler_grids, but you also have similar examples from Chris’ post above. However, your case will look a bit different because the exact remapping weights will need to be tailored to the ACCESS-OM2 configuration.
If you’d like to get in touch to discuss, would be happy to chat. I have been meaning to set up this kind of scenario (forcing an OM2-like simulation using coupled model inputs), but never took the plunge on it yet.
First, thank you for the many links/input/recommendations. There is now a viable plan to try and get this to work.
Below is a list of the JRA55-do variables used in ACCESS-OM2 (properties are taken from here), and what I think their corresponding variables in the ESM1.5 UM are. All the UM output below is saved 3-hourly, and the time and time_0 variables are the staggered 3h time coordinate.
JRA55-do variable
UM atm variable
UM Dimension
UM Description
tas 10m air temperature (θA), units: K
fld_s03i236
(time, lat, lon)
TEMPERATURE AT 1.5M units : K
huss 10m specific humidity (qA), units: Kg kg−1
fld_s03i237
(time, lat, lon)
SPECIFIC HUMIDITY AT 1.5M
uas 10m eastward wind, units: m −s 1
fld_s03i209
(time, lat, lon_u)
10 METRE WIND U-COMP
vas 10m northward wind, units: m −s 1
fld_s03i210
( time, lat_v, lon)
10 METRE WIND V-COMP
psl Sea level pressure (SLP), units: Pa
fld_s00i409
(time, lat, lon)
PRESSURE AFTER TIMESTEP units :Pa
rsds Downward shortwave (QDSW), units: Wm−2
fld_s01i201
(time_0, lat, lon)
NET DOWN SURFACE SW FLUX: SW TS ONLY units :W m-2
rlds Downward longwave (QDLW) , units: Wm−2
fld_s02i201
(time_0, lat, lon)
NET DOWN SURFACE LW RAD FLUX units :W m-2
prra Rainfall flux, units: kg m ^{-2} s ^{-1},
fld_s05i214
(time_0, lat, lon)
RAINFALL RATE: LS+CONV KG/M2/S
prsn Snowfall flux , units: kg m ^{-2} s ^{-1}
fld_s05i215
(time_0, lat, lon)
TOTAL SNOWFALL RATE: LS+CONV KG/M2/S
friver Total river runoff , units: kg m ^{-2} s ^{-1},
missing friver from ESM?
licalvf Solid water runoff from Antarctica represented as calving flux from Depoorter et al. (2013), units: kg m ^{-2} s ^{-1}
missing from ESM?
Here I have outlined the approximate next steps and the links to the scripts/resources I will likely use. Warning, all this is hypothetical and the list will grow, but I will keep this thread updated.
what to do for missing friver/licalvf values – just use JRA55-do RYF input?
Initial conditions: I would like to use the historical ESM1.5 ocean/ice restart files from /g/data/vk83/configurations/inputs/access-esm1p5/modern/historical/restart/ and feed that into ACCESS-OM2. The file names match up, but in OM2 each nc file is split. (‘ocean_neutral.res.nc.0000’, ‘ocean_neutral.res.nc.0001’ etc in OM2 for example, vs. ‘ocean_neutral.res.nc’) Would this naming situation would affect me using the ESM ocean/ice restarts? unaffected, but can collate as suggested two replies down.
Need to interpolate the ocean restart files, as the ESM1.5 and OM2 have different ocean vertical resolution
One final thing: For science reasons, it has been thrown out there for my project that using ACCESS-OM3 would be useful. The pros are isopycnal coordinates and that changing the forcing could be easier with NUOPC (my vague understanding from what Chris said above?). The cons are that OM3 is still in development, and that there is some documentation now (here in this thread!) on how this could be done in OM2. I will be at ANU Thu-Fri this week, so will try to catch a few people in person but any opinions on this here are very welcome. @ShayneM
Cheers everyone,
Ellie
P.S. I am also aware of a running list of potential problems that can occur when changing the forcing for ACCESS-OM2 as outlined here. I don’t think they currently apply but will keep in mind.
This is not a problem - ACCESS-OM2 will handle collated restarts (without .0000 etc) just fine.
It’s best to use an identical topography and vertical grid so you don’t have any uninitialised wet points (or if not, to extrapolate fields horizontally into all the land points - there are tools for that).
Hi @ongqingyee,
Sounds great - I should be around on Thursday and Friday at ANU too.
In regards to uncollated restarts, I would just collate them yourself for simplicity of looking at and interrogating the files. You can borrow the mppnccombine executable specified from one of your config.yaml settings. If you simply run that executable on its own it gives you a user prompt on how to run it.
Please note: ACCESS-ESM1.5 and ACCESS-OM2-1deg do not use the same vertical grid. So, if transplanting an ocean restart file from one to the other, be mindful of the need to re-interpolate vertical structure, especially in relation to missing grid cells.
You could force one of them to use the vertical grid of the other… perhaps that’s breaking things too much though.
Hi @ongqingyee, just answering your email query here in case it is or interest to others:
We generate initial conditions by regridding WOA data using this script
which handles vertical regridding and horizontal extrapolation into all land points. I expect with a bit of effort it could be adapted to create ACCESS-OM2 initial conditions from ACCESS-ESM1.5 restarts.
