-
Notifications
You must be signed in to change notification settings - Fork 0
CableUserGuide_Configuration
CABLE can be used in many configurations, in part determined by the input files supplied to the code.
All points simulated by CABLE are independent of each other. Therefore, a group of points can be collapsed into a single vector irrespective of their real geographical location. In the online situation, this is done by packing and unpacking data at the interface where the host model is coupled to CABLE. In the offline situation, this is done in the initial I/O stage. Two formats are supported for the met forcing file and the output file; either data is given only for land points (preferable to reduce file size) or all points are given with a mask specified to differentiate land and ocean points and facilitate conversion to a single vector. Compared to CABLE-1.4b, CABLE-2.0 now supports tiling of vegetation, i.e. multiple vegetation types with specified area fractions for a single location/grid-cell (also referred to as patches in CABLE). The length of the single vector passed to CABLE is then determined by the number of land points and the number of active patches (those with non-zero patch fraction) at each land point.
CABLE’s behaviour is determined by the values chosen for a large number of parameters. These parameters are often set to vary by vegetation type and soil type. In the CABLE v2.0 distribution, we provide default parameter sets for a particular set of vegetation types (Appendix A) and soil types. However there is no requirement for CABLE to use these default values or this particular set of vegetation types, except that vegetation type 16 is currently reserved for lakes, and vegetation type 17 is reserved for permanent ice. Permanent ice must always have a patch fraction of 1.0. For ACCESS, care must be taken to ensure that the specification of vegetation type is consistent with other parts of the ACCESS code, e.g. the dust scheme needs to know the bare ground type (currently set to type 14).
For single-site simulations, site-specific parameters can be specified, effectively bypassing the default values set for a given vegetation or soil type.
Here we summarize CABLE input requirements for single-site offline, regional/global offline and online implementations. Table 1 lists the different types of input files used across offline and online cases. Each file type will be discussed in turn.
Table 1: Input files used by CABLE in offline and online implementations
| Offline | Online (ACCESS) | |
| Namelist (different variables relevant depending on implementation) | ||
| Vegetation parameter file | ||
| Soil parameter file | ||
| Input | Surface data file | Vegetation and soil ancillary files: |
| Vegetation fraction | ||
| Vegetation function (LAI and canopy height) | ||
| Soil properties | ||
| Meteorological forcing | - | |
| Restart file | CABLE variables incorporated into UM restart | |
The namelist file for CABLE is cable.nml. For offline applications it should be located in the directory in which you are running CABLE. For ACCESS cases, cable.nml should be located in ~/CABLE-AUX/UM on the machine that CABLE is being executed on.
The cable.nml includes some settings that are common across all CABLE applications and others that are required only for offline applications. Annotated examples of cable.nml are provided in ~/CABLE-AUX/UM for ACCESS applications and in CABLE-AUX/offline for offline applications.
This file sets a range of parameters that depend on vegetation type such as leaf length and width, vcmax and reflectance and transmittance parameters. The file location is set using filename%veg in cable.nml. A default vegetation parameter file is provided in CABLE-AUX/core/biogeophys/def_veg_params.2.0a.txt (def_veg_params.1.8a.txt contains the parameters used in the ACCESS1.3 CMIP5 runs.) Parameters are provided for 11 vegetated types, and 3 non-vegetated types with 3 types currently not used (12, 13, 15-urban). Also note that type 10 (c4 crop) is not currently used in ACCESS cases. For each vegetation type, the file format is:
1 forest evergreen_needleleaf ! veg number, type and name 17.0 0.01 0.001 0.055 0.0 ! canopy hgt(m),leaf angle,lf width(m),lf length(m),C4 frac 0.043 0.211 0.010 0.160 0.390 0.010 ! rholeaf-vis,nir,therm, rhowood-vis,nir,therm 0.035 0.120 0.010 0.001 0.001 0.010 ! tauleaf-vis,nir,therm, tauwood-vis,nir,therm 0.100 0.225 0.020 1.00 ! rhosoil-vis,nir,therm; xalbnir 8.6 1.0 0.10 2.0 9.0 0.001 ! LAImax(m2/m2),WoodAI(m2/m2),canst1,shelrb,vegcf,extkn 40.0e-6 3.0000 0.0832 1.0 ! vcmax(mol/m2/s), rp20, rpcoeff(/oC), rs20 -15 -10 2.0 0.943 ! tvjmin(oC), tvjmax(oC), vbeta, betaroot 200 10217 876 184 367 ! pool: leaf, wood, root, soilfast, soilslow (gC/m2) 1.0 0.03 0.14 2.0 0.5 ! rate: leaf, wood, root, soilfast, soilslow (/year)
Note that parameters and names in red are not used in CABLE-2.0 while parameters/names in blue are only used under some circumstances. The carbon pool and rate parameters and rp20, vegcf and rs20 (respiration parameters) are not used if CASA-CNP is running. rs20 is used if the namelist parameter cable_user%DIAG_SOIL_RESP = ‘OFF’, otherwise vegcf is used.
The vegetation parameter file format differs from that used in CABLE-1.4b. The old file format can still be used by setting the CABLE namelist variable vegparmnew=.false..
It is important to note that there are cases where CABLE will overwrite values that have been set in the vegetation parameter file: ACCESS cases: canopy height is overwritten by spatially explicit canopy height, read in from a UM ancillary file (see Section 5.1.4); for non-vegetated surfaces canopy height is set to zero in the CABLE code, overwriting values in the parameter file and the ancillary file. Offline cases: parameter values will be overwritten by any site-specific values that are provided in the meteorological forcing file (Section 5.1.5) or in a restart file (Section 5.1.6).
The chosen parameter values in offline cases can be checked against pre-defined realistic parameter value ranges using the CABLE namelist variable check%ranges=.true. .
The soil parameter file sets a range of parameters that depend on soil type. The file location is set using filename%soil in cable.nml. A default soil type parameter file is in CABLE-AUX/core/biogeophys/def_soil_params.2.0a.txt.
For offline CABLE cases, the parameters from this file are only used when the CABLE namelist variable soilparmnew is set to .FALSE.. For ACCESS cases, the parameter values in the file for isoil=9 are used for grid-cells with permanent ice, and the rhosoil and css values for isoil=2 are used for all non-ice tiles. Other soil variables (and rhosoil and css in the offline case) are now input as spatially explicit fields in the files described in Section 5.1.4. Finally in the offline case, site-specific soil parameters can also be read from the meteorological forcing file (Section 5.1.5) or the restart file (Section 5.1.6).
CABLE requires some input variables to be specified by longitude and latitude. For offline simulations all the required input is combined into a single netcdf file, the location of which is specified by the filename%type variable in the CABLE namelist. For ACCESS simulations the variables are input through UM ancillary files or the model start dump, the locations of which are set through the UMUI. The following variables are required:
a. Vegetation distribution. Each grid-cell is allocated one or multiple vegetation types.
**For offline simulations**, two variables are required iveg(longitude, latitude, patch), containing
integer vegetation types and patchfrac(longitude, latitude, patch), containing the fraction of the
grid-cell with that type. The patch dimension is the maximum number of different vegetation types
defined for each grid-cell. The size of the patch dimension is read from the input file. An example
file is *CABLE-AUX/offline/gridinfo_CSIRO_1x1.nc* based on the vegetation types listed in [[Appendix A|CableUserGuide_Appendices]].
The vegetation distribution is applicable to 2005 and is based on Lawrence et al. (2012) with some
aggregation of types as described in Kowalczyk et al. (submitted to AMOJ). In this case only one
vegetation type is used for each grid-cell, the patch dimension is set equal to 1, and the patch
dimension has been dropped from the iveg array. From these arrays, CABLE determines how many
patches are active and need to be simulated; those with a patch fraction of zero are ignored.
In single-site offline cases, a default vegetation type will be read from this ‘gridinfo’ file based on
the site location. The vegetation type can be overwritten if it is set in the meteorological forcing
file (Section [[5.1.5|CableUserGuide_Configuration]]).
**For ACCESS atmosphere only simulations,**the vegetation distribution is set through the UM
‘fractions of surface types’ ancillary file. The file is specified through the UMUI using
''Atmosphere/Ancillary and input data files/ Climatologies & potential climatologies / Vegetation
distribution: Area and structure.'' The ancillary file gives the spatial distribution of every vegetation
type as a fraction of the land-area of each grid-cell. Thus, at any land grid-cell the vegetation
fractions sum to one, even if the land fraction is less than one (for coastal points and small islands).
As in the offline case, CABLE does not execute for vegetation fractions of zero.
The ancillary file can be set up to have a single time (fixed vegetation), in which case the
‘configured’ option is chosen in the UMUI window or multiple times (varying vegetation), in which
case the ‘updated from ancil’ option is chosen, and the frequency of update is entered. Note that
current ACCESS code will, by default, interpolate between sequential vegetation distributions
which may not be the desired behaviour for land-use change simulations. A ‘no interpolation’ case
is being tested. Example vegetation distribution files for 1850 and 2005 are provided on *vayu* in
*/data/projects/access/ancil/access_v2*, with filenames *cable_vegfracN96.1850.anc* and
*cable_vegfracN96.2005.anc* respectively. These are the files used in the ACCESS1.3 CMIP5
simulations and are described in Kowalczyk et al. (submitted to AMOJ). If a time-varying
vegetation distribution is required, note that CABLE must simulate all vegetation types that will
occur at any time within the simulation in any given grid-cell. To ensure that this occurs, set
vegetation types to a small but non-zero number (e.g. 1e-5) for periods when they are not present.
CABLE-2.0 has yet to be tested in ACCESS coupled model simulations but in that case the initial
vegetation distribution is read from the start dump.
The example files for both offline and ACCESS simulations use the vegetation types listed in [[Appendix A|CableUserGuide_Appendices]].
b. **Leaf Area Index (LAI).**A time-varying field, usually derived from satellite data. When CASA-CNP is fully functional, LAI can be simulated rather than prescribed.
**For offline simulations,**LAI is specified in the LAI(longitude, latitude, patch, time) array in the
same input file as the vegetation distribution. In the example file, the LAI data are monthly and are
taken from MODIS collection 5 (Gau et al., 2008; Ganguly et al., 2008) averaged over August 2002
to March 2009.
For single-site simulations, site-specific LAI can be included in the meteorological forcing file and
will overwrite the default values taken from this input file.
**For ACCESS atmosphere-only simulations**, LAI is prescribed in the ‘plant functional types’
ancillary file which is specified through the UMUI using *Atmosphere/Ancillary and input data files/*
*Climatologies & potential climatologies / Vegetation distribution: Area and structure.* LAI is defined
separately for each vegetated type. For non-vegetated types, LAI is explicitly set to zero within the
CABLE code. Note that the example file, *cable_vegfunc_N96.anc* in
*/data/projects/access/ancil/access_v2*, which was used for ACCESS1.3 CMIP5 simulations
(Kowalczyk et al., submitted to AMOJ), has a single LAI value for each grid-cell regardless of
vegetation type. In the example file LAI has monthly temporal resolution and in ACCESS1.3
simulations this was interpolated to a 5 day frequency.
c. **Canopy height.**Not applicable to offline cases. Can include temporal variation.
**For ACCESS atmosphere-only simulations,**canopy height is prescribed in the same ‘plant
functional types’ file as the LAI. In the example file, the canopy height is fixed for each vegetation
type, at the same values as in the example vegetation parameter file. The vegetation parameter file
values are overwritten by those in this ancillary file. Note that the ancillary file also includes a
canopy conductance field but this is not used by CABLE-2.0.
d. **Soil type and soil properties.**Soil properties are either determined based on soil type (offline only) or each soil property field is set separately (offline and online).
**For offline simulations,**the method for setting soil properties is determined by the CABLE
namelist variable *soilparmnew*. If *soilparmnew*=.false., the variable isoil(longitude, latitude) is read
from the surface data input file to define the soil type. The soil type is used with the parameters in
the soil parameter file (Section [[5.1.3|CableUserGuide_Configuration]]) to set soil properties. For single-site simulations, the default soil
type from the surface data input file will be overwritten by any soil type set in the meteorological
forcing file (Section [[5.1.5|CableUserGuide_Configuration]]). Default soil properties for that type will then be used. In the example file,
soil type is based on Zobler (1998). Snow-free surface albedo split by radiation band (variable
name, Albedo) is also read.
If *soilparmnew=.true.,* spatially varying soil texture (clay, silt and sand percentages), soil properties
(swilt, sfc, ssat, bch, hyds, sucs, rhosoil, cnsd, css – see [[Appendix C|CableUserGuide_Appendices]]) and snow-free ground albedo
(albedo2, not split by radiation band) will be read from the surface data input file. In the example
file, the soil properties are generated from the same data sources as used in the UM (IGBP-DIS;
Global Soil Data Task, 2000 , http://daac.ornl.gov/SOILS/guides/igbp-surfaces.html) and are
provided at 1° resolution. Site-specific soil property values can also be specified in the met forcing
file but care needs to be taken to ensure the properties are self-consistent, especially when a
mixture of default and user selected values are used.
**For online simulations,** most soil properties are provided through an ancillary file, such as
*/data/projects/access/ancil/access_v2/qrparm.soil_ch* for all soil types except permanent ice
(which uses values from the soil parameter file)**.** The ancillary file contains two fields that are not
used: soil carbon content and the field labeled ‘Stash code = 8’ (believed to be soil density). Soil
density (rhosoil) and soil specific heat capacity (css) are set through the soil parameter file and use
the values for soil type 2 everywhere except for permanent ice, which uses the soil type 9 values.
e. CASA-CNP inputs. Nitrogen and phosphorus inputs, soil order and grid area
**For offline simulations** Ndep, Nfix, Pwea, Pdust, soil order and grid area are read from the surface
data input file. The example file is provided at 1° resolution. Note that it is not possible to set these
variables in the met forcing file to overwrite the input file values. This capability may be added
with future CASA-CNP developments.
**For online simulations,**input will be through a UM ancillary file. This has not been set up for the
CABLE-2.0 release.
f. Soil moisture, temperature and snow depth – initialization values
**For offline simulations,**initial soil moisture (SoilMoist), soil temperature (SoilTemp) and snow
depth (SnowDepth) can be read from the surface data input file. These would be used if a spin-up
is not performed and if there is no restart file. In general, it is recommended that spin-ups are
performed especially after changes in vegetation or soil types or parameter values or algorithms
within CABLE.
**For online simulations,**initialization values are taken from the start dump. The start dump needs
to come from an ACCESS run with the correct number of soil levels for CABLE (six) and a land-sea
mask consistent with the other ancillary files being used for the simulation. An example is
available on *vayu*, */data/projects/access/ACCESS_initial/atm/hg3_cable_PD.astart*. Note that this
file, used for ACCESS1.3 CMIP5 AMIP runs, has no snow which impacts at least the first year of any
simulation. A replacement start dump needs to be created and tested. CABLE requires soil
moisture, soil temperature and some snow fields to have a tile dimension (which MOSES does not)
and consequently these variables are defined as user prognostics, and their method of
initialization is set in the UMUI through *STASH/Initialisation of User Prognostics.*
The meteorological forcing file is a collection of meteorological variables that need to be read into CABLE's 'met' arrays with the correct units. The filename is set using the CABLE namelist variable filename%met. Netcdf format is used, broadly conforming to the ALMA standard .
a. It must contain a double precision real time(time) variable, which is the time value, in seconds, of each time step since the starting time value. The starting time value is obtained from the "units" field for the time variable, and is of the form: "seconds since 2001-02-22 00:00:00".
It is not essential that this "start time" be the start time of the simulation, e.g. the first value of the
"time" variable may be 86400, in which case the actual start time might be 2001-02-22 00:00:00 +
86400 seconds; i.e. 2001-02-23 00:00:00.
The "time" value for regional or global simulations is assumed to be GMT, while the value for single
site/grid cell simulations is assumed to be local. Single site simulation "time" values will be read as
GMT if and only if a "coordinate" field is present for the "time" variable and set to be "GMT". This
time coordinate system will be reported in the log file.
CABLE’s time step size is calculated from the first two values of the *time* variable, and the run
length of the simulation is decided by the length of this same variable.
b. Multiple site/regional/global simulations can use either an x-y grid input file or a land only compressed grid-type input file. For the x-y grid, an "x" and a "y" dimension must be present, even if the simulation is only a single site/gridpoint. Additionally, single precision variables named "latitude" and "longitude" (or "nav_lat" and "nav_lon" if using ALMA formatting), both dependent on the x and y dimensions only, must be present. Both sea and land points may be included by using an integer mask(x,y) variable; a value of 1 implies a land gridpoint, anything else is assumed to be ocean. For the single dimension land only “compression by gathering” grid (see http://www.lmd.jussieu.fr/~polcher/ALMA/dataformats.html), a single spatial dimension is used. An example of the netcdf header from such a file is shown in Appendix F. c. Note that the number of points simulated by offline CABLE is not specified in the code, but determined here using the number of land points found in the met file. If a patch dimension exists, the patchfrac variable gives the fraction of each vegetation patch in each land gridpoint. CABLE counts the number of ‘active’ patches (patches with non-zero patchfrac) as the number of points for simulation. d. Meteorological variables, broadly conforming to the ALMA standard, are of dimension 3 (x,y,t) or 4 (x,y,z,t) if using the x-y grid, or 2 (land, t) if using the compressed grid. All must have a text "units" field. Essential variables are: SWdown, Tair, Qair, Rainf, Wind (or Wind_N and Wind_E); and "optional" variables are: LWdown (can be synthesised from Tair), PSurf (can be estimated at a fixed value based on Tair and an "elevation" variable), Snowf (assumed to be included in Rainf if not present) and CO2air (assumes a fixed value, determined in the cable.nml namelist file). Note that for PSurf to be estimated, a variable "elevation", dependent on x and y dimensions or the single ‘land’ dimension (as appropriate), must be present. e. Site-specific parameters recorded in the met file will overwrite the default values obtained during initialization. For example, the default value of za (reference height or measurement height) is 40 m; it will be overwritten by the value read from the restart file, if present, and then overwritten by the value read from the met file, if present. Please see Appendix B for the symbols/names and dimensions used for each parameter. Except for LAI, all these parameters are expected to be constant in time and mostly of dimension (x,y) or (land). With LAI, CABLE can distinguish constant, monthly, daily or time step values and read in accordingly.
It is possible to check that the ranges of input variables are appropriate using check%ranges=.TRUE. in cable.nml.
Met input data must be continuous in time if date/time variables are going to be correct. An example input file is provided with the CABLE release. Users can download the original TumbaFluxnet.1.3_flux.nc (or its equivalent in subsequent versions) from PALS (http://www.pals.unsw.edu.au/pals/Welcome.action). Note that there are data for many FluxNet sites available at PALS. The format of these data files is compatible with that required by CABLE. The script ConvertMetForLSM.R (CABLE-AUX/offline) was used to add some site-specific parameters (hc, za, iveg and frac4) which are now present in the file provided. This allows the users to do a test run of CABLE on their own systems. Output from the run should be uploaded to PALS for plotting and comparison to the default case.
As discussed in Section 3.2.3, the global offline simulations use multiple met files, one for each meteorological variable recorded in compressed grid method. These met forcing data can be downloaded from the GSWP-2 website. If you are interested in global offline simulations, please contact [mailto:[email protected] [email protected]].
In the offline case, restart files are optional as input to CABLE. The path to the restart file can be set in cable.nml (Section 5.1.1) using the filename%restart_in variable. The restart data file contains initial state values for necessary variables, as well as a complete set of the parameters which were used in the run which created the restart file. The driver will by default look for a restart file.
The restart file will be read in before model simulation. If no such file exists, the default (and rather crude) initial values for all variables will be used; as mentioned above, those site-specific parameters present in the met file will overwrite their corresponding default values. To create a restart file, simply set the namelist variable output%restart=.true. – then when a run finishes, the final states and parameters used will be written to a restart file. The name of the output restart file is set by the namelist variable filename%restart_out variable. This facility is useful in conjunction with the spin-up facility (Section 5.3) – if output%restart=.TRUE. for the spin-up simulation, when states have converged, a restart file will be written saving the need to spin-up again if a repeat run is required.
ACCESS simulations: prognostic variables required to restart CABLE are written into the UM dump (restart) files automatically.
Precedence of input methods: As described in Section 5.1, CABLE receives input values by a variety of methods. It is important that users are clear about how their parameters are being set, and which input method takes precedence. For offline simulations, the log file provides information about what parameter values were used in the simulation.
Consistency of parameters: When prescribing only a subset of the parameters in the met file, take care to avoid parameter inconsistencies. Particular care should be taken if a mixture of user-defined and default parameters are being used.
For most purposes CABLE should have a 'spin-up' period, forced with a year (or several years) of meteorological data until its internal states stabilise. To this end, the namelist file has a logical variable which may be set to '.TRUE.' for a (limited) automatic spin-up. The driver will then run the specified filename%met file repeatedly until soil moisture and soil temperature stabilise. Stabilisation is defined by the 'delsoilM' and 'delsoilT' variables, set in the namelist file. They define the allowed variation in each of these two variables in any soil layer in the final time step between consecutive spin-up runs of filename%met. When these variables stabilise, the data set will be run one more time and output written. Note that in a regional or global simulation this may take some time!
There are several reasons why a model spin-up may not produce reasonable initial states. Firstly, the input data set period may not be representative. Ideally, the model would spin-up using observed meteorological forcing data from the period preceding the simulation period that the states be as realistic as possible. Using the same data set for spin-up and simulation could mean that the soil moisture initialisation, for example, is too dry when the data set represents drought years. To try to avoid this problem, the netcdf driver looks for an 'avPrecip' variable in the meteorological input file. This variable has no time dependence (it has a single value for each grid cell) and represents the average precipitation value for the particular grid cell/site, in mm. If 'spinup=.TRUE' in the namelist file and the 'avPrecip' variable is found, precipitation values read from the meteorological data input file will be rescaled to match this value, for the duration of the spin-up only. If information about rainfall patterns in the pre-simulation period is available, avPrecip should be set appropriately.
This release of CABLE comes with a set of CASA-CNP codes which are compiled with CABLE by default in the offline case only (Section 7. notes the status of the ACCESS version of CASA-CNP). Also, when using CASA-CNP in an offline simulation, please note that the spin-up of initial pool sizes is preliminary and not yet available with this release; users should do their own spin-up to get suitable initial values of all pool sizes.
Controls: The use of CASA-CNP can be controlled by the CABLE namelist variables icycle and l_casacnp. The switch l_casacnp is redundant although it still has to be switched on (value set to .TRUE.) when icycle is non-zero. The module also requires the use of the spatially-specific soil texture values activated by setting the CABLE namelist variable soilparmnew to .TRUE. (Section 5.1.4). These settings will be checked by the offline code. As the soil textures (sand, silt and clay fractions) have been part of the CABLE parameter set from the start, these values can be introduced via the meteorological forcing file, overwriting any values given in the surface data file. Note that other CASA-CNP parameters have not been set up to take site-specific values from the meteorological forcing file yet.
| icycle | description | *soilparmnew* | *l_laiFeedbk* | *l_vcmaxFeedbk* |
| 0 | Not using CASA-CNP; but using old version of carbon module. | User’s choice | Not available | Not available |
| 1 | Using CASA-CNP, but carbon cycle only. | .TRUE. | User’s choice | Not available |
| 2 | Using CASA-CNP, with both carbon and nitrogen cycles. | .TRUE. | User’s choice | User’s choice |
| 3 | Using CASA-CNP, with carbon, nitrogen and phosphorus cycles. | .TRUE. | User’s choice | User’s choice |
Normally, CABLE uses prescribed LAI read from the input file specified by the filename%type variable (Section 5.1.4) or from the meteorological forcing file. When the CABLE namelist variable l_laiFeedbk is switched on, CASA-CNP will calculate LAI values to be passed back to CABLE for use. These prognostic LAI values would be written out in the output file. When in this configuration, the code will check to make sure that CASA-CNP has been turned on.
CASA-CNP can also be used to predict the vegetation parameter vcmax which is normally prescribed in the input file specified by the filename%veg variable (e.g. def_veg_params.txt mentioned in Section 5.1.2). This is controlled by the CABLE namelist variable l_vcmaxFeedbk and requires the nitrogen cycle to be turned on (i.e. icycle =2 or 3).
Input files:
- The example file CABLE-AUX/offline/gridinfo_CSIRO_1x1.nc as specified by filename%type contains datasets needed for CASA-CNP, namely grid area, soil order, soil textures and nutrients. They have been described in Section 5.1.4.
- Another file specified by the CABLE namelist variable casafile%cnpipool is needed to initialize the nutrient pool sizes within CASA-CNP. An example file is provided for the single-site standard test (CABLE-AUX/core/biogeochem/poolcnpInTumbarumba.csv). For regional or global offline simulations, a file of pool sizes for all the land points/patches simulated by CABLE is required.
- The file specified by the CABLE namelist variable casafile%cnpbiome is a collection of lookup tables used by CASA-CNP. The example file is CABLE-AUX/core/biogeochem/pftlookup_csiro_v16_17tiles.csv.
- The file specified by the CABLE namelist variable casafile%phen is a latitudinal listing of phenology dates for various vegetation types. The example file is CABLE-AUX/core/biogeochem/modis_phenology_csiro.txt.
Output files:
The default output file from this module is called poolcnpOut.csv which can be changed using the CABLE namelist variable casafile%cnpepool. This file contains the pool sizes of all the simulated points at the end of the whole simulation. It can be renamed and fed back to another simulation for the purpose of spinning up the nutrient pools.
Other outputs from the CASA-CNP module are passed back to CABLE and written in the default output file out_cable.nc.
If you are interested in using CASA-CNP or have any questions, please contact [mailto:[email protected] [email protected]] so that you can be kept up to date with CASA-CNP developments.