There is potential value in being able to run CABLE standalone for one or more locations (sites) using forcing taken from ACCESS model simulations. This may be an easier option for investigating different behaviour between online and offline simulations as a step towards running global simulations.
This topic captures notes associated with this task.
Getting met forcing from ACCESS-ESM1.5
Timeseries output from grid-cells is needed. The list of grid-cells is supplied through the domain field defined in the STASHC file for an ACCESS-ESM1.5 run. Examples are DGTS_PT (21 locations, probably mostly flux towers), DCO2TS (locations of atmospheric CO2 monitoring sites), DCO2TSL (similar to DCO2TS but for variables defined on model levels rather than just at the surface).
The required time field in STASHC is TALLTS.
The variables to be output are listed in the STASHC file by section and number. This is what I have currently used to match up with what CABLE requires
| Section | Number | StashMaster | CABLE |
|---|---|---|---|
| 0 | 409 | SURFACE PRESSURE AFTER TIMESTEP | Psurf |
| 1 | 235 | TOTAL DOWNWARD SURFACE SW FLUX | SWdown |
| 2 | 207 | DOWNWARD LW RAD FLUX: SURFACE | LWdown |
| 3 | 230 | 10 METRE WIND SPEED ON C GRID | Wind |
| 3 | 236 | TEMPERATURE AT 1.5M | Tair |
| 3 | 237 | SPECIFIC HUMIDITY AT 1.5M | Qair |
| 5 | 216 | TOTAL PRECIPITATION RATE KG/M2/S | Rainf |
In an ESM1.5 set-up, the output is requested in the STASHC file using syntax like this:
&STREQ IMOD= 1, ISEC=0, ITEM=409, IDOM=33, ITIM=19, IUSE=12 /
In this case the DGTS_PT domain is the 33rd in the file, and the TALLTS time field is the 19th in the file. IUSE determines which output file the data is written to. In this case it goes to *.pg files.
If adding output requests to the STASHC file, remember to increase the number (NUM_REQ) at the top of the file
&STASHNUM NUM_REQ= 280, NUM_DOM=37, NUM_TIM=20, NUM_USE=12 /
Note that the radiation output will be at the 3 hourly radiation timestep. Other output will be half-hourly.
Update June 2024
CABLE standalone needs to be run with the temperature and specific humidity from the lowest ACCESS model level not the 1.5 m values. These stash outputs were used.
| Section | Number | StashMaster | CABLE |
|---|---|---|---|
| 16 | 4 | TEMPERATURE ON THETA LEVELS | Tair |
| 0 | 10 | SPECIFIC HUMIDITY AFTER TIMESTEP | Qair |
Note that since these are multi-level fields, a new output domain is required to specify the level. This has been set up for the pft-focussed 13-site set of grid-cells described in a later post.
Do we want to add the atmospheric CO2 concentration to that list? Is it possible to output it in that way?
Hi @clairecarouge , yes - at some point we will probably want to add CO2. At this stage I was just trying to document what Iâd done so far.
Re-formatting ACCESS output for CABLE standalone site input
This documents the steps I used to convert ACCESS output to a file that CABLE standalone could use. Not all steps may be required and there will, no doubt, be better and more efficient ways to do this. The ACCESS output was for the DGTS_PT domain which is 21 grid-cells. The 9th in the list matches the approximate location of the Tumbarumba flux tower site.
After all this, CABLE ran and appeared to give plausible results. Now we just need a cleaner way of doing this.
The time variable needs more work. I note that the documentation says it should be double precision. In my reformatting I donât seem to have enough precision - the timestep calculation was OK in my first run but when trying to restart and run for an extra year, it wasnât OK, 1808s instead of 1800s.
Also from the restarted run, the log file tells me that the run goes from 2004 to 2005 but the output netcdf file has time running from 2001.
Set of grid-cells to focus on each pft
Chose a set of grid-cells for testing to represent each pft. If possible, used a grid-cell with tile fraction = 1.0 and land fraction = 1.0. If not, found a grid-cell with as large a fraction as possible and retaining a land fraction = 1.0.
For ESM1.5, these grid-cells were chosen. Domains for stash output are DTS_PFT for single level variables and DTS_PFTL1 for variables on atmospheric levels.
| PFT | E-W index | N-S index | Longitude | Latitude | Fraction |
|---|---|---|---|---|---|
| Evergreen needleleaf | 30 | 123 | 54.375 | 62.5 | 1 |
| Evergreen broadleaf | 155 | 68 | -71.25 | -6.25 | 1 |
| Deciduous needleleaf | 64 | 124 | 118.125 | 63.75 | 1 |
| Deciduous broadleaf | 160 | 57 | -61.9 | -20 | 0.9173 |
| Shrub | 80 | 50 | 148.1 | -28.8 | 0.7123 |
| C3 grass | 140 | 111 | -99.375 | 47.5 | 1 |
| C4 grass | 19 | 78 | 33.8 | 6.2 | 0.9818 |
| Tundra | 43 | 127 | 78.75 | 67.5 | 1 |
| Crop | 41 | 99 | 75 | 32.5 | 1 |
| Wetlands | 42 | 124 | 76.875 | 63.75 | 0.6975 |
| Bareground | 6 | 93 | 9.375 | 25 | 1 |
| Lakes | 27 | 108 | 48.75 | 43.75 | 1 |
| Ice | 73 | 9 | 135 | -80 | 1 |
Made a CABLE met file with all 13 grid-cells i.e. no longer required the cdo,selgridcell step above.
Running CABLE standalone for multiple sites identified a bug. See Defined ncid_mask for met data files with multiple sites. Fixes #306.
Creating an ACCESS âgridinfoâ file
CABLE standalone runs use âgridinfo_CSIRO_1x1.ncâ for some initial data or parameters/ancillary data if it is not available in met or restart files. For site runs, data is taken from the nearest 1 degree by 1 degree grid-cell. To ensure ACCESS values were used in the CABLE standalone tests, a new gridinfo file has been created at ACCESS resolution.
Most of the fields required for the gridinfo file are available from an ACCESS restart. For these tests, the ârestartâ created for the start of the simulations was used (PI-PFT-01c.astart-01010101). Used /g/data/p66/rml599/Site-tests/conv2nc.tcl to convert this list of fields from the restart to netcdf
set fieldlist "3 11 13 27 28 29 30 31 32 33 90 95 98 142 143 144 230 231 232 233 234 235"
Output is /g/data/p66/rml599/Site-tests/access.astart101.nc
This table matches the variable in the gridinfo file with the field number from the restart and the variable name in access.astart101.nc
| Gridinfo | Field no. | access-file | Notes |
|---|---|---|---|
| area | Used cmorised areacella_fx | ||
| iveg | 95 | field1391 | On tiles, pick dominant |
| patchfrac | |||
| isoil | Set to 2 for all veg types except 17 when set to 9 | ||
| SoilMoist | 3 | sm | Convert from kg/m2 to m3/m3. Divide by soil layer thickness and rho_water (1000) |
| SoilTemp | 11 | soiltemp | |
| SnowDepth | Still to be added. Currently set to 0. | ||
| Albedo | Dummy value, 0.2 - not used but checked so needs to be sensible | ||
| LAI | 235 | temp_5 | On tiles so selected LAI for dominant veg type |
| SoilOrder | 230 | temp | Convert to integer |
| Ndep | 231 | temp_1 | Need to multiply by 365. |
| Nfix | 232 | temp_2 | |
| Pwea | 234 | temp_4 | |
| Pdust | 233 | temp_3 | |
| clay | 142 | field1630 | |
| silt | 143 | field1631 | |
| sand | 144 | field1632 | |
| swilt | 27 | field329 | |
| sfc | 28 | field330 | |
| ssat | 29 | field332 | |
| bch | 90 | field1381 | |
| hyds | 30 | field333 | Need to divide by 1000. |
| sucs | 33 | field342 | |
| rhosoil | Set according to isoil, 1600. for isoil=2, 910. for isoil=9 | ||
| cnsd | 32 | field336 | |
| css | Set according to isoil, 850. for isoil=2, 2100. for isoil=9 | ||
| albedo2 | 98 | field1395 |
Gridinfo_CSIRO_1x1.nc has monthly values for SoilMoist, SoilTemp and SnowDepth. Currently January values have been copied into all months since the other months are not being used.
Very ugly code to write an ACCESS gridinfo file is /g/data/p66/rml599/Site-tests/writegridinfo.F90. Output is /g/data/p66/rml599/Site-tests/gridinfo.access101.nc
Hi Rachel,
A basic question: where on Gadi do the created astart files live? I thought they might be in fs38, but they donât seem to be.
Hi Lachlan,
The released ACCESS-ESM1.5 configurations should point to restart/astart files. Looking at the config.yaml, it has this location listed
/g/data/vk83/configurations/inputs/access-esm1p5/modern/pre-industrial/restart/
Under the atmosphere sub-directory there is a file PI-02.astart-01010101
For my current test runs (using script-based not payu runs), all restarts end up in /scratch/p66/rml599/archive/RUN/restart/atm
Great, thanks. Iâll take a look there.
Based of the stash variable list that Tammas sent, the STASHmaster_A ârecommendedâ by the fields file at /g/data/vk83/configurations/inputs/access-esm1p5/modern/pre-industrial/restart/PI-02.astart-01010101 represents a different STASHmaster_A than either under /g/data/vk83/configurations/inputs/access-esm1p5/share/atmosphere.
Still a bit confusing as it seems like there are more fields in the fields file than entries in the new STASH provided by Tammas. Doing some more digging to see if I can interpret exactly how these files work.
Managed to get xconv working on my local machine and deciphering it now. How did you know that those unnamed variables (Stash code = xxx) were what you say they are? They donât match with Tammasâ document. Is there some document somewhere?
Hi @lachlanswhyborn, I donât think any of us have a definitive document. It is something I have thought needs documenting - the cable variable name, the variable name used when passed through the UM, then the field code.
One thing to be aware of is that all the 8?? numbers are CABLE prognostics. Numbers in the .astart file that are 38?? should be the equivalent variable but they are diagnostics, so it seems that in PI-02.astart-01010101 there is one entry for field 801, and two for field 3801. Iâm guessing 801 is the one the restart will use and will be the instantaneous value at the start time. The 3801 ones may be for calculating monthly or daily means?
As to âhow did I knowâ - I think some of it was just matching what was in the astart file with what was in the gridinfo file i.e. the numbers/distribution matched.
Perhaps between Tammas, you and I we should write a definitive list.
The other potential trap is that we co-opted some UM/JULES variables to use for CABLE and these have retained their UM names even if we have used them for something slightly different.
On the âhow did you knowâ part, do you mean plotting the UM fields and the CABLE default gridinfo fields side by side and making a bit of a âcommon senseâ judgement that yes, these are the same fields?
Actually, further question- what is the provenance of the data in this UM restart file? Are the 8?? fields relating to CABLE generated from some down sampling of default CABLE gridinfo, or something else?
Iâll start doing up a document that can eventually go either with the CABLE documentation or perhaps the CABLE-as-ACCESS configuration, starting from the table you created above.
Yes to plotting fields side by side.
My understanding is that at least some of the gridinfo fields (e.g. soil ancillary information) are originally derived from the UM fields as used by MOSES (predecessor to JULES) in the ACCESS1.3 era.
Other fields, e.g. for CASA, may have started as datasets for the offline case and were later adapted for ACCESS. Other data (nitrogen deposition?) may be a CMIP6 input.
Fields that are prognostic variables (soil moisture, temp etc) will have come from spin-up runs which would be independently generated for ACCESS and offline.
I have a couple of questions about some finer details:
pftlookup.csv and I found LAImax and LAImin, but not a per-vegetation type LAI. The current CABLE gridinfo does not seem to have a per vegetation type LAI.cable_parameters.F90 under case(6)? (source code here)Hi @lachlanswhyborn,
Yes - you have correctly identified the soil level thicknesses (zse).
LAI is a lat, long, pft, time array. It can either be prescribed through an ancillary file (along with vegetation height). In this case it will have monthly values to capture seasonal changes. It is also possible to run with prognostic LAI, which is what we would usually do when running ACCESS-ESM. This means that the LAI and the carbon leaf pool are linked.
Prognostic LAI is set in cable.nml
l_laiFeedbk = .TRUE. ! using prognostic LAI
l_vcmaxFeedbk = .TRUE. ! using prognostic Vcmax
We run with both prognostic feedbacks on. I forget whether they are completely independent.
If you look at a restart file using xconv, the prescribed LAI is called âLEAF AREA INDEX OF PLANT FUNC TYPESâ. While it is defined for the 13 potential vegetated types, it is the same for all pfts in an ACCESS-ESM1.5 restart, as it is only in ACCESS-CM2 that we moved to having prescribed LAIs that were different for each pft.
Prognostic LAI is âStash code = 893â - you will see that this one does vary with pft (and is defined for all 17 veg types, even the non-vegetated ones).
Ah yep I think I understand now. The lon x lat x PFT array in the UM fields file defines an LAI on every grid cell for every PFT, so take the LAI corresponding to the dominant PFT selected from iveg. Looks like you copied that data to all the months based on your conversion script?
It appears that you do at least something with the SnowDepth in your conversion script, based on this snowdepth.nc file. Does that file just contain zeros?
I copied the LAI data to all months because I knew I wasnât going to use anything other than the first month but the gridinfo file needed all months. This was because I was running with prognostic LAI so once it was initialised, it wouldnât need any other information.
The snowdepth file contains three fields that came from the restart file and are for stash code 819, 820 and 821. This should be the snow in three layers on pfts. In my âwritegridinfoâ code, I multiply by the pft fraction and sum over pfts and over the three layers to get the snow depth for the gridinfo file. I ignored land fraction so Iâm not sure if coastal points would be correct but none of the sites I was running offline were coastal points.
This certainly gave me some snow where I needed it - but I wasnât convinced that Iâd got the correct amount.