I am seeking help on reconfiguring the land surface (CABLE) restart files as I would like to “unglaciate” Antarctica in ACCESS-ESM1.5. I have tried changing the PFT fraction:
For PFT fraction, this is “field1391” when converting the UM binary to netcdf using conv2nc.tcl, or alternatively, it is ITEM_CODE == 216 when using the um_replace_field.py script in the access utilities.
If I try to modify the restart file to use a single vegetation type (e.g. set type 0 to 1.0 everywhere, which is evergreen needleaf), and all other types to zero, the model will crash.
If I try to change a single cell of the Antarctic Peninsula to be not ice, but some other type, the model will crash.
If rather than just editing PFT variable, I copy all of the variables from a grid cell at the bottom of South America to a grid cell on the Antarctic Peninsula, then the model will run.
This leads me to believe that if I want to unglaciate Antarctica, there are other key variables that need to be changed in tandem with PFT fraction. I have no idea which variables are critical to change in that regard. Anybody know how to make wholesale changes to land surface properties in ACCESS-ESM?
Hi Tammas,
Funnily enough, I tried exactly this approach just now - using a Tundra grid cell from Alaska to “export” to Antarctica and Greenland. It seems to work, which is a relief. Thanks a lot!
Arghhh - there was a power failure and I have to re-write everything here.
The UM has spatial fields (per grid cell) for soil properties/parameters. We use these in CABLE, and so SoilType is largely irrelevant. However, ICE regions(Antarctica/Greenland) are treated differently. We adopt the soil type parameters as declared for soil type = ICE (as in CABLE offline). The only way to identify ICE regions is via the PFT distribution map. This mostly agrees with the spatial soil maps in that where the PFT map says there is ICE. (Basically we say where PFT=ICE, set SoilType=ICE) the spatial soil maps agree (well conversely). I.e. We have only identified a few cells on the coast of Greenland where the soil maps describe a Tundra situation but the PFT map prescribed ICE. This raises an unknown (for me at least) whether the SoilType=ICE parameters are tuned to represent the km thick ICE surface of Antarctica, or the soil underneath, and the snow model treats this as packed snow, glacier etc. Re-declaring the PFT type present as Tundra will effectively remove this clobbering with “our” SoilType=ICE parameters. BUT, you will inherit the original JULES parameters that describe this ICEd region. Soil/snow fields such as moisture, temp etc evolve dynamically in the model and there are numerous occasions where PFT type = ICE (mostly PFT type, but sometimes SoilType) receives special treatment. So you would be avoiding these as well. In short, I am skeptical that just changing the PFT description and substituting some Tudra soil fields will consistently describe a deglaciated Antarctica. The albedo might even be indicative of ICE, well this is somewhat inside of one of those IF(ICE) loops, nonetheless typical of the degree of tangling here.
Sorry for the slow reply. To follow up on this, I did a remapping of all variables that were “packed” to the land mask. That means that albedo and every other restart variable that has missing values outside the “land” points are exported from a tundra location to the new “unglaciated” Antarctic cells, using my script.
It’s a brute force solution, but if the origin cell of the “tundra” being exported has appropriate values for these fields you mention, then I am copying those values across in bulk.
NRUN is just the UM speak for the new (first chunk of the experiment) run, CRUN for continuation run.
Sorry, I just had another thought related to the tile_fraction field, which I suspect you have already accounted for.
So where it was Antarctica (except the coast) the tile_fraction was ice=1. IF the substituted Tundra region/cell has Tundra=1, this won’t matter:
Apart from soil fields, presumably your script picks up all the fields which have dimensions (land_pts, ntiles).
IF Tundra==1, then all ntiles then picking up only Tundra, (land_pts, 8), because effectively (land_pts, ntiles)==(land_pts, 8) anyway.
However, IF Tundra<1, then all ntiles are needed.
There are checks in the UM code (tile_pts.F90 from memory) that tile_fraction sums to 1 at each land point - so it should fall over anyway, however I can’t exactly recall the extent to which this is still intact. I’m pretty sure it is.