The project aims at running the ACCESS-N48 coupled ocean-atmosphere model in Eocene topographic and orographic configuration.
Our current problem is that we cannot change the ancillary files in any way.
As a starting we would like to run the ACCESS-N48 with a change in moving Australia to a different location, to test that we can run the model. This is likely to involve ancillary files of both atmosphere and ocean model.
The need for this was discussed in today’s panel discussion. This was a focus in particular for Nicky Wright. I’ll see if she wants to join in the discussion here.
Thanks Aidan!
Happy to help where I can, though I don’t have much successful experience in actually setting up a deep-time run.
I’m guessing you’re starting with the Early Eocene setup from here?
Well, we thought of starting with just a simple test case in which we shift Australia to new location. this should test all elements we would need to do any kind of deep paleo configuration.
Yes having this capability with ACCESS will open up many scientific opportunities and additional ways to test the model which (at least in the US CESM2 example I gave) fed into constraining its future projections. Hopefully the ancillary file issue is something easy to fix, @atteggiani @MartinDix
For the UM ancillary files, in the library we are building there are still a couple of things that need to be addressed, such as the consistency with land-mask file and the sensibility of some values (e.g. negative temperatures or concentrations, fractional land < 0 or > 0, etc.). This for the regridding tool.
The ancillary modifier tool (to modify ancillaries starting from NetCDF files) instead, is ready and should work with any UM ancillary.
We are waiting for all the issues with the regridding tool to be fixed to release all in a single library.
However, if you have ancillary files to modify using netCDF file relative to the Eocene period in your experiment, please let me know the respective directories and I’ll be happy to test the ancillary modifier tool on those files. @abhik @Dietmar_Dommenget
For changing/regridding the Ocean input files, instead, there are a few more problems and I have no experience with Ocean files. I am checking what’s already available and it is under discussion if our library should/can include also the possibility to modify Ocean files.
Some COSIMA people might be able to tell you (us!) more about this. Maybe @aekiss @navidcy @rmholmes?
Cheers
Davide
There are some instructions for changing topography and land masks in the ocean for these kinds of things in the wiki at Tutorials · COSIMA/access-om2 Wiki · GitHub. A few people have used this, including myself (for closing off the ITF) and some of @LaurieM’s students. If you have any problems let us know!
Thanks, @atteggiani and ACCESS-NRI team.
For testing the ancillary modifier tool, you can use the original Eocene files in /g/data/n69/sza565/ancil-from-uk/JASMIN_input_data.tar.gz
These files were built on the JASMIN system in the UK, some tools/libraries may not be readily available on NCI.
However, for the consistent ocean-atmosphere coupled ACCESS ancillary files, the ancillary file creation process should start from a single bathymetry file to generate the land-ocean mask and coupling weights. The same land-ocean mask file should be used to create topography, river routing, and other required ancillary files.
Please follow the Eocene suite setup guideline file for your reference.
@rmholmes Could you please update the input file location at Tutorials · COSIMA/access-om2 Wiki · GitHub
We wish to generate a new set of ocean bathymetry and land-sea mask following your tutorial for the paleoclimate experiment that @Dietmar_Dommenget mentioned above.
The N48 coupled model is not supported by ACCESS-NRI, right? If we wanted to run some paleo-simulation could we get access to it? I guess it is quite faster than the ACCESS-ESM, right? That could work well for our planned Pliocene exp.
Hi, I am also interested in using an ACCESS coupled model for deep time simulations. My targets are Miocene (15 Ma) and Oligocene (30 Ma), but I have previously simulated Eocene climates using GFDL CM2.1. I had planned to use ACCESS-ESM1.5, but would also be keen to know if it’s possible using the N48 atmosphere. Would be interested to collaborate and/or discuss issues around setting up the boundary conditions for the atmosphere and land models.
Well, the idea is that we develop the N48 version, so that people can use it, but we are not quite there yet. And yes, it is much fast and cheaper. It runs about 30yrs per CPU day, potentially it can be faster than that.
I’ve updated the paths in that tutorial now to something that should work for Gadi (I haven’t tested it). Note the specific paths you use depend on the configuration you’re using (e.g. JRA55 v1.3 vs v1.4 vs. coupled etc., your own custom_topog_test directory, the remapping files appropriate for your resolution etc.). If you run into any problems please let me know.
@rmholmes the exe file
/g/data/ik11/inputs/access-om2/bin/fms_ACCESS-OM_1c1f23e_libaccessom2_b6caeab.x
doesn’t exist. But there are many other similar exe files in the same directory. Can I use any of them alternatively?
We don’t need cice file as our planned experiments will be run in sea-ice-free conditions. Will there be any issue with the output ocean_mask.nc file if we don’t use the generated kmt.nc file in the experiment?
What are you trying to do exactly? Are you trying to run a version of ACCESS-OM2 to test that your changes to the topography and masking works properly? If so, then I’d suggest working from one of the up-to-date default configurations, which will have all the right paths for you (e.g.
GitHub - COSIMA/1deg_jra55_ryf: 1 degree ACCESS-OM2 experiment with JRA55 RYF atmospheric forcing.).
If instead you’re trying to use the coupled model (without sea ice), then some of the details of how you use the topog.nc, ocean_mask.nc may be different (depending on whether the coupled model uses payu, and thus config.yaml to run or not). Also the remapping files will be different because of the coupling. In this case I don’t think you’ll be able to use the ACCESS-OM2 make_remap_weights.py script to make your remapping files, although you might be able to adapt it to work. I’d expect that the topogtools should be fine still to produce the mask file (and you can probably just ignore the kmt.nc file)?
If you are working with the coupled model I’m probably the wrong person to help.
Thanks, @rmholmes. Our experiments will be conducted in O-A coupled N48 framework. Using a given topography file, I could create an ocean_mask.nc file through topog2mask.py (with minor modifications in the code). However, we perhaps need to adopt a different approach for generating coupling weights as you suggested.
Any help from others on this would be much appreciated.
Hi Dietmar, could you please provide a rough guide for how many CPUs is required for the N48 coupled model? For the N96 version we have the following numbers:
ACCESS-ESM1.5: CPUs: 384, Model cost 1.1kSU/year, Walltime: 16 years/day
Do you have something similar for N48?
Regards, David
Dear ACCESS-NRI,
to make some progress here we currently like to know how we can edit the ancillary files of the ACCESS-N48 coupled model. In particular, we need to know:
What ancillary files of the atmos, ocean and coupler to we need to edit to change topography/orography and land-sea mask for atmos and ocean?
How can we edit these ancillary files?
Is there something else we need to consider in this context?
best regards
Dietmar
Dear David,
good point. Abhik would know. As far as I know the model runs 1yrs simulation in 40min wall time.
best regards
Dietmar
@dkhutch Our coupled N48 uses 480 CPUs and completes 2 calendar years simulation in 1 hr 40 mins. Therefore, the computational cost is 480x1.67x2 = 1.6 kSU/2yrs or 0.8 kSU/yr.
The N48 suite should complete ~30 yrs/day. However, we merely get 20 yrs/day in reality. Our suite can run ~2 years only in a single job and resubmits another job for the next 2 yrs. This reduces the actual efficiency of the suite as often the jobs wait in the queue.
How can we improve efficiency by running longer than the usual 2 years in a single queued job?