New Input Routines for Met Forcing

Overview of new Met Input Routines

There is a first pass at a set of new input routines to handle the meteorological forcing, on a CABLE branch which has been forked from the CABLE-POP_TRENDY. The driving factor behind this work has been to run the TRENDY configuration at ACCESS resolution.

The Changes

The goal is to have routines that accept generic datasets that span over multiple files. We require that the files are named such at the start and end date of the data in the file are specified in the filename. Take the ACCESS-ESM1.5 historical data for precipitation as an example: The data from 1850 to 2014 is contained in


To set this as the forcing dataset for precipitation, the namelist entry would be:


where we have replaced the dates in the filenames with <startdate> and <enddate>. This allows the code to determine each of the files which form the dataset, and the time periods relating to each file.

Ideally, we would inspect the NetCDF attributes of the files to determine the time periods, but not all datasets of interest are yet CF compliant. If the dataset is not already named in a way that matches this template, you can symlink the original files to new names that match the template using ln.

Configuring the Met Forcing

An additional change is to move the internal configuration options controlled by the Run option in the Met namelist to the Met namelist directly. These options control the recycling of the Met forcing and the atmospheric CO2 and N deposition.


The new input routines are contained in the 212-POP-Prepare-for-CMIP6 branch, and a demo configuration containing the new namelist options in the met namelist (namelists/cru.nml) are contained on the 5-Update-Configuration-for-Met-Refactor branch of the TRENDY_V12 configuration repository.


This is a first pass at a new set of routines, so I would like to get feedback from users regarding suggestions, scenarios where you think this approach may fail or other concerns you have. This “style” of specifying time-varying inputs is something we’d like to roll out across the code in the future, after further iterations with some back and forth with the land community.