At the ESM WG meeting on 23rd May, it was mentioned that ACCESS-NRI is seeking community input into priorities for their next model release targets. From a paleoclimate perspective, we list some examples which we would like to be available in ACCESS-NRI supported release(s) of ACCESS-ESM1.5. This is intended to stimulate discussion and give an idea of possibilities.
Topography changes: An example of making large-scale changes to the topography and land-sea mask. This could be a release of an already-running simulation (e.g. Miocene, 49 ka glacial, or idealised ENSO experiments). The goal is to make it flexible, so that a new user could pick up the workflow and apply it to a new and different scenario.
Vegetation changes: An example of how to reconfigure the plant functional types and ice coverage. We have some examples where we have been able to make changes to the vegetation (e.g. Last Interglacial, 49 ka glacial), but also others where we have tried to implement different vegetation or ice and the model crashes immediately. It would be great to have a worked example of how to make wholesale changes to vegetation to an arbitrary set of inputs.
Orbital Forcing: An example of how to easily change orbital parameters. Previously, users have had to ask a CLEX CMS member to recompile the UM any time we want to change the orbital parameters (e.g. 49 ka or Last Interglacial). Could we please obtain a working compile script to do this ourselves? Changing orbital forcing requires specifying 3 parameters: obliquity, eccentricity and longitude of perihelion. Ideally we could specify these 3 numbers, run a script, and have a new UM executable with the desired orbital forcing.
Freshwater forcing: An example implementation of freshwater hosing. We have a few working examples of this (North Atlantic freshwater hosing), and I believe others have done it for the Southern Ocean in ACCESS-ESM1.5 (e.g. Ariaan Purich).
Calendar issues: Not as high priority, but when running ACCESS-ESM1.5, we can only use the Gregorian calendar, and this has caused some simulations to crash. It would be simpler if we could use “no-leap”. UM doesn’t support a no-leap calendar, but perhaps could be implemented? Alternatively, if we could be given an example implementation of a 360-day calendar (this is supported by the UM and MOM5, but we don’t know how to do that for the CICE model).
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
2
Thanks for kicking off a discussion @dkhutch, and these are all great suggestions.
I’d characterise your points as “capabilities”, i.e. we would like the capability to be able to …
So is it more important for the community that ACCESS-NRI develops capabilities (tools, documentation, examples) that researchers can use to create their own configurations, or fully fledged configurations that can be used “off-the-shelf”?
Clearly the answer to that question depends on the composition of the community, and what research questions they’re answering.
Would it be correct to say that paleoclimate researchers are less interested in “standard” configurations? That there aren’t as many commonalities in paleo as, say, present-day and near-future climate scenarios? In which case, are capabilities more important for paleo than standard configs?
Or would there be a set of fairly standard paleo configs that could be used as a starting point for a number of researchers, saving them the hassle of changing pretty much everything? And thorough documentation of the how the standard configurations were generated would serve a dual purpose of explaining how this might be done for other configurations?
Thanks Aidan,
You’re right that capabilities for customisation are of great interest to the paleoclimate modelling community. I could imagine that some carefully chosen “release” experiments could serve a dual-purpose in this regard.
The Last Interglacial (127 ka) is a good example, because it’s been done before in ACCESS-ESM1.5, and it’s also part of the CMIP fast track. @nyeung has been running 127 ka experiments for much of his PhD, but if someone else wanted to simulate a new time period (e.g. the Last Glacial Maximum; 21 ka), we don’t have the workflow available to change the orbital parameters ourselves. If you had an example release which came with its own customisable orbital parameter generation, that would open up lots of possibilities for new users.
Same goes for the Miocene climate optimum (15 Ma) - it could serve as an example model release of how to do points (1) and (2) above, but it’s only going to be truly useful for opening new pathways if it comes with all the steps that went into generating the new topography. I can sort of show people how to do what I’ve done, but I don’t have exemplary software management or training skills, hence ACCESS-NRI could help improve that process so that it is more accessible for new users.
I think there is value in having specific releases for these kind of experimental setups, because people want an end-to-end solution. I.e. A new student has some set of boundary conditions from a new MIP, and wants to see how that flows through all the way to doing payu run on the experiment.
Speed: For paleo studies we need to be able to run long (~1000yrs) simulations. For this it is essential to know how the model can be run fast. So, it would be good to know which elements of the model could be turned off to make it faster.
Stability: For the same reason the model has to run stable. So, the job scripts need to be organised that they do not crash very few years.
In response to @Aidan question: standard runs vs. own development: we need both, but developing your own experiments is far more interesting, and it is the part where we really need support.
In support, meaning people at ACCESS NRI that can help us getting whatever experiment we want running. This would require the ACCESS NRI to have in-depth understanding of all elements of the ACCESS model (e.g. code, physics, numerics, ancillaries, etc.).
I agree that having a fast model is important for paleoclimate purposes. I keep using the GFDL CM2.1 model for this purpose. My version of it uses approx 10% of the resources of ACCESS-ESM1.5. So, I can run with either 48 or 96 cpus and it runs ~30 or ~45 years per day respectively.
If there was an ACCESS model with N48 atmosphere that might have potential to do similar things. Also should bear in mind that the ocean resolution in ACCESS-ESM1.5 is not especially optimised for long simulations. It has 300 x 360 x 50 grid cells (notionally 1 x 1 deg), and a lot of latitudinal grid refinement in the Southern Ocean and tropics.
My GFDL configuration has 175 x 240 x 50 grid cells (notionally 1 x 1.5 deg), and no latitudinal grid refinement anywhere. The upshot is my model has only 39% of the number of ocean grid cells as ACCESS-ESM1.5, but I would argue its ability to resolve ocean gateways is actually not much worse. Just a thought.
One could imagine, for argument’s sake, in a “fast” model you could use 1.5º lat x 2.0º lon x 40 levels, which would amount to 120 x 180 x 40 grid cells, i.e. 16% of the ACCESS-ESM1.5 resolution.
1 Like
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
8
This is MOM5 I suppose? So if this was a desirable configuration we could “repurpose” the MOM5 grid?
Yes, it’s MOM5.1 as in ACCESS-ESM1.5
I mainly mention this because if we are considering moving the atmosphere from N96 (approx 1.5 deg) to N48 (approx 3 deg), then we might also consider economising the ocean grid cells.
I just want to clarify that we would still want to use the current version of the ACCESS-ESM1.5 for paleo-studies, and that a more “user friendly” version would be very helpful.
In addition, a faster, lower resolution version of the ACCESS-ESM could be useful for sensitivity experiments. In this lower resolution version, the priority is a simplification of the atmospheric model.
Hi @dkhutch,
Good call on the calendar issues. I have had a student looking at the ESM 1.5 large ensemble and there is quite a strong signal in clear sky short wave radiation, particularly in the southern hemisphere that we traced back to occurring in leap years (see attached screenshot).
Thanks @ShayneM that’s good to know. I must admit I don’t fully understand the plots, but if you’ve got issues that are generated by leap years then that’s good information for the community to know about.
