Run CABLE-POP at ACCESS Resolution

It is useful to run CABLE-POP offline at ACCESS (N96) resolution to

  • more easily compare CABLE-POP performance to ACCESS performance
  • as a potential contribution to spinning up ACCESS land / land carbon
  • to test sensitivity to parameters or other inputs / ancillaries
  • CMIP7 is expected to include offline land-only simulations.

Two cases potentially useful:

  • Re-grid of Trendy forcing to ACCESS resolution for direct comparison with current CABLE-POP submission to Trendy.
  • ACCESS meteorology

Required tasks / questions to address

  1. Scope what is required to change resolution
    a. Meteorology forcing files
    b. Other input files
  2. CABLE-POP currently run with daily data and a weather generator. Is it worth testing sensitivity to this vs more frequent data?
  3. Is the ACCESS resolution dataset previously prepared useful? May need to check provenance. Also note this is interpolated to give higher frequency data.
  4. Re-format ACCESS meteorology to be suitable for use by CABLE-POP (or re-write CABLE-POP to read ACCESS netcdf output). Does ACCESS need to be re-run to give data at appropriate temporal frequency? Initial aim would be 10-20 years from pre-industrial simulation to be used for spin-up.
  5. Compare CABLE-POP internally generated vegetation distribution for 1750/1850 with ACCESS pre-industrial.
  6. Test whether CABLE-POP can run with vegetation distribution derived from ACCESS (but reduced to single tree type, single grass type)
  7. Convert LUH2 for POP transition files to ACCESS resolution.

NOTE: There is a half-grid shift between the N96 grid used in ACCESS-ESM1.5 compared with later versions (ACCESS-CM2+) and hence the land-sea mask is different. Initial work on CABLE-POP at ACCESS resolution will need to be on the ACCESS-ESM1.5 grid but new files will be required for working with ACCESS-AM3/CM3/ESM3.

TRENDY forcing requirements and CMOR equivalents
There are (up to) 11 forcing variables needed to run CABLE-POP in the TRENDY set up. Of these 8 are readily available (i.e. at the correct temporal resolution, gridded, for at least 1950 onwards) via the CMIP6 CMOR archive on fs38 (historical simulation), 1 variable is available but would require further processing, 1 requires further thought and 1 is unavailable.

The 8 variables available are [TRENDY netcdf name, CMOR name, {CMOR section}]

  1. daily total precipitation flux [rain, pr, {day}]
  2. daily downwelling longwave radiation at the surface [dlwrf, rlds, {day}]
  3. daily total downwelling shortwave radiation at the surface [tswrf, rsds, {day}]
  4. daily averaged (2m) specific humidity [spfh, huss, {day}]
  5. daily maximum (2m) air temperature [tmax, tasmax, {day}]
  6. daily minimum (2m) air temperature [tmin, tasmin, {day}]
  7. daily (10m) easterly wind component [ugrd, uas, {day}]
  8. daily (10m) northerly wind component [vgrd, vas, {day}]

These variables would need some attention to change variable names and check units. The wind variables could be substituted for the CMOR variable sfcWind (and a set of zeros) if sensible.

The variable requiring further processing is

  • daily surface pressure [pres, surface value of the 3D field ps]

ps (and specifically the surface value of ps - which should not be substituted by the mean sea level pressure psl) is a variable in the {CFday} section but does not appear to have been archived on fs38. However ps has been archived at 6-hourly intervals in the {6hrLev} section. It should be relatively simple to post-process this to an appropriate daily averaged, surface level variable.

The variable(s) that requires further thought are

  • atmospheric CO2 (in ppm) - the TRENDY configuration uses a single, annual and globally average value. The ESM could provide interactive temporo-spatial fields, CM2/CM3 will be using prescribed time series.
  • Nitrogen deposition and other scenario dependent ancillaries.

The variable that is not available in CMOR (and hence fs38) is

  • fraction of downwelling shortwave radiation that is diffuse [df].

This variable could be constructed from CMOR variables rsdsdiff and rsds, however rsdsdiff does not appear to have been archived.

Note: This variable is not compulsory for TRENDY (prior to TRENDY v11 this input was not available) and the code can default to using a fixed fraction (50:50 direct:diffuse) if this is not supplied. Hence, for our purposes (testing and spin up), the lack of a true input for [fd] is unlikely to be critical.

Some post-processing is likely required for all variables to ensure that the grid is compatible (e.g. the appropriate latitude, longitude ranges are used, ensure date-time is as expected, appropriate metadata is embedded) and (potentially) to concatenate the CMOR files into longer time series.