Run CABLE-POP at ACCESS Resolution

Land Surface CABLE
1

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.

2

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.

2 Likes
3

@inh599 , we will need to decide on what to do with CO2. @lachlanswhyborn is starting to look into this. We can do a first proof of concept version with a constant CO2 in the namelist file (hopefully works with POP) and add the CO2 later but it will be good to have something soon.

4

Agreed that we need to think about this - especially for testing. @Juergen your thoughts?

I canā€™t actually remember if POP uses CO2 directly - or just inherits CO2 dependent fields from CABLE and CASA. If it does require CO2 directly, POP will inherit this as the met%ca variable from CABLE.

In TRENDY-style runs we use an annually varying, globally constant value which is read in via a text file and then spread across all land points. In ACCESS I suspect we will need to organise for an annual-average of (the time-space varying) met%ca to be evaluated (this may already exist as part of the casa_sumflux% TYPE and would be easy to add to the climate% TYPE if it doesnā€™t exist) and then pass that to POP.

5

POP does not need CO2 concentrations at all.

met%ca is only needed in cable and (maybe) casa.

For TRENDY they provide annual, globally constant, CO2 values. They also provide the option of reading in monthly, globally constant, CO2 values. I have not done that switch yet and still read in the annual values.

We could relatively easily switch to spatial-temporal fields of CO2 I think as weā€™d just have to follow the procedure for other variables.

1 Like
6

For concentration-driven ACCESS runs, we only use one global number for CO2, varying in time (probably just annually). So spatially-temporally changing CO2 will only be needed in an emissions-driven case. Iā€™m assuming for something like the land-hist run in Fast Track, that will be prescribed CO2 not interactive.
Start with the simplest option - a single met@ca.

1 Like
7

@lachlanswhyborn is looking into this and I think we need some help to decide what we need to start from. @Juergen I assume you are the best person to ask.

The question boils down to how much we need to follow the TRENDY setup for this CABLE at ACCESS resolution.

We want to run with POP and for the moment, the only setup @lachlanswhyborn and myself know is the TRENDY workflow. This workflow is using the CRU met. forcing but there is a lot of work done directly within CABLE to figure out what to read from CRU, all (or most of it) in cable_cru_TRENDY.F90. But this file does not seem particularly easy to adapt to other datasets. We are now wondering what is the best way to do this.

Do we need to do our best to copy what is needed for CRU in TRENDY because we know it works? Or can we ā€œsimplyā€ put in CABLE that we are using GSWP3 or something simpler? I believe we have to follow CRU for TRENDY but I want to be sure before going there.

In the cable_cru_TRENDY.F90 code there are a lot of cases for things like: S0_TRENDY, S0_TRENDY_Temp, S2_TRENDY_precip0 etc. Do we have to worry about these? Do we only need to do one case for the run at ACCESS resolution? If there is an explanation of what all these cases are that would be useful too. Is there a case we should pick to follow? I see the run_TRENDY.sh we have going is using S0 but not sure about the subcases.

8

Yes, thatā€™s a good point and a general issue with the CABLE code (and generally with land surface models I guess). The met input routines are specific to the forcing and itā€™s hard to write code that can deal with all kinds of forcing products and formats (or it would require more pre-processing). So in CABLE the solution was often to write an entirely new input routine (there is another one called ā€˜plumeā€™ and I think I have seen one for GSWP3 as well).

Itā€™s always best to use and modify an existing routine. Thatā€™s the best option if the forcing is similar to those that CABLE is already set up for. It sounds like thatā€™s the best option for you. Can you remind me what you would like to run? Is that cru forcing at ACCESS resolution? So would the spatial resolution be the only difference to a TRENDY run?

Regarding the cases in the code (S0_TRENDY, S0_TRENDY_Temp, etc.). I think those were sub-cases in earlier TRENDY experiments that Vanessa ran. It is confusing to have them in the code so I will try to clean it up in June/July this year. The bottom line is that you do not have to worry about it. TRENDY runs are set up for 4 experiments: S0 - S3. You specify those in the run_TRENDY.sh script and it figures everything else out. Itā€™s not set-up for any other test cases and they can be ignored.

Let me know if you have more questions and/or we can discuss on Thursday.

9

I think we are interested in both cases:

  • running with CRU forcing at ACCESS resolution - so we just look at the sensitivity of CABLE-POP to spatial resolution / pft distribution
  • running with ACCESS meteorology - hopefully with can use whichever input code is closest to the format of ACCESS meteorology

YPW had always advocated for only one input routine and everything else done as a pre-processing step. How is the meteorology input routine in JULES set up? Is it any cleaner than our code?

10

Thanks @Juergen , itā€™s helpful to know.

@lachlanswhyborn is working on running with ACCESS meteorology but maybe we can quickly get the TRENDY configuration (CRU + ancillaries) at ACCESS (-ESM1.5) resolution going.

I havenā€™t looked at JULES yet but that is a good idea. From what I have seen in CABLEā€™s input routines, it seems a lot could be done via generic routines + namelist options instead. That would be more flexible and easier to add a new forcing. There might still be the need for a small core of specific routines per forcing dataset but likely much less than what is done now. So @lachlanswhyborn is trying to implement the CMIP format in a ā€œgenericā€ way. We are not looking at expanding to other met. forcings as itā€™s out of scope for CMIP7 and we donā€™t have the time now. But that could help us build a base to work from afterwards.

11

I agree that writing a generic input routine for CABLE would be a good investment and would things easier. I think weā€™d still need some code to tell the model what to do for specific experiments but the majority of the work could be moved to the pre-processing.

and let me guess: you have a separate input routine for the ACCESS meteorology?

12

thanks, that makes sense.

13

I donā€™t think there is a separate routine right now. We will start as a separate routine since redesigning the whole thing would be too time-consuming during our CMIP7 development. But try and design it to be more generic.

14

I think it might be better from a time constraint point of view to work with the CRU input routines to handle the ACCESS meteorology, as we have all the same variables. This way we might be able to leave the code in cable_driver.f90 untouched. I can leave the current POP branch of the code as is, so there is historical record of the configuration of these ā€œS0ā€, ā€œS1ā€ etc. experiments.

15

Hereā€™s a link to the small set of slides I was trying to show at the meeting today (18/04).
CABLE4-Meeting-2024-04-11.pdf (315.9 KB)

16

Iā€™ve made a stand-alone topic regarding the new meteorological input routines here. It contains links to both the CABLE branch with the new routines, and the TRENDY_V12 configuration branch with the namelist changes.

17

A strange issue with the ACCESS met forcing. The vas met dataset is of different dimensions to the rest of the met forcing, with spatial dimensions of 144x195, while the rest are 145x192. Any clue as to why that might be?

18

This is because quantities can be calculated at the middle of a grid cell or on the edges. In the UM, the winds are calculated on the vertices:

  • vas is ā€œshiftedā€ by half a grid cell in latitude compared to temperature for example
  • uas is ā€œshiftedā€ by half a grid cell in longitude compared to temperature

And the centre of the gridcell (well, half grid cell) at the poles is right on +/-90Ā°, so there is one less edge than centre. Whereas the grid is cyclic in longitude so same dimension for uas even if the data is shifted.

Edit: I have no idea how we want to handle the ā€œmissingā€ wind speed.

19

Hi @lachlanswhyborn, the UM uses a staggered grid - depending on the variable it is defined at the centre or the edge of the grid-cell (I think). We also need to be a bit careful with the vertical levels as well, they may be defined on ā€˜rhoā€™ or ā€˜thetaā€™ levels - one is half way between the other.

For my single site testing, Iā€™ve been using these fields which I think/hope were all on the same grid - but perhaps weā€™d need to re-run ACCESS to get all of these out at daily resolution - so perhaps we can just start with interpolating what weā€™ve got to match up the grids.
Section and number
0, 409 surface pressure
1, 235 total downward surface sw flux
2, 207 downward longwave rad flux: surface
3, 230 10 m wind speed
5, 216 precip
16, 4 temperature on theta levels
0, 10 specific humidity

20

@lachlanswhyborn @clairecarouge Unless CABLE-POP technically requires both components of the wind (uas and vas) I think we should be able to use the standard ACCESS/CMOR variable sfcWind. This output variable will have the grid shift applied correctly.

Even if we do need both components as inputs it may be simpler to use sfcWind in one field and a set of zeros in the other. They will be being used in the vector magnitude (i.e. as sqrt(uas x uas + vas x vas) ) within CABLE unless something is really odd (see around line 255 in cable_cru_TRENDY.F90)