Constraints.RmdThe Hector model can be run subject to constraints that force the model to have certain behavior. Technically, this means that the model’s components output user-provided data as opposed to their own calculations, similar to the data mode of a CESM sub-model. Currently the available constraints include:
If the current input file includes, in its [temperature] section, a line of form
tgav_constrain=csv:path/to/constraint/file.csvthen the model’s global mean temperature Tgav will follow this contents of this file (which should have two columns, Date and tgav_constrain; a sample file is included in the repository). The model will extrapolate within this data as necessary, but not beyond its endpoints.
Once Hector’s internal date passes the last date in the constraint file, the model’s temperature component becomes unconstrained, except that we do not permit it to suddenly jump to a new temperature. Instead, changes in global radiative forcing (from which temperature change is computed) are applied to the end-of-constraint temperature. For more details, see the detailed comments in the TemperatureComponent::run method.
If the current input file includes, in its [forcing] section, a line of form
Ftot_constrain=csv:path/to/constraint/file.csvthen the model’s global radiative forcing Ftot, that drives global temperature changes, will follow this contents of this file (which should have two columns, Date and Ftot_constrain). The model will extrapolate within this data as necessary, but not beyond its endpoints. Once Hector’s internal date passes the last date in the constraint file, the model’s forcing component becomes unconstrained.
If the current input file includes, in its [ocean] section, a line of form
oceanflux_constrain=csv:path/to/constraint/file.csvthen the model’s ocean carbon uptake (in Pg C) will follow this contents of this file (which should have two columns, Date and oceanflux_constrain). The model will extrapolate within this data as necessary, but not beyond its endpoints. Once Hector’s internal date passes the last date in the constraint file, the model’s ocean uptake becomes unconstrained.
If the current input file includes, in its [simpleNbox] section, a line of form
CO2_constrain=csv:path/to/constraint/file.csvthen the model’s atmospheric CO\(_2\) concentration ([CO2], given in ppmv CO\(_2\)) will follow the contents of this file (which should have two columns, Date and CO2_constrain). Alternatively, Hector’s atmospheric CO\(_2\) concentration constraint can be set using the setvars function and CO2_CONSTRAIN variable.
The CO\(_2\) constraint is applied at the end of the current time step. The full sequence of events is as follows: First, the model solves the current time-step’s carbon cycle conditioned on the previous time step’s carbon pools, ignoring the CO\(_2\) constraint. Then, if a CO\(_2\) constraint is present, Hector calculates the difference between its calculated atmospheric CO\(_2\) and the prescribed CO2 constraint. If the target atmospheric CO\(_2\) concentration is lower than the calculated CO\(_2\), the excess carbon is transferred from the atmosphere to the deep ocean; conversely, if the target atmospheric CO\(_2\) concentration is greater than the calculated value, the additional carbon is transferred from the deep ocean into the atmosphere. Finally, Hector records the current atmospheric CO\(_2\) concentration (which is now equal to the constraint value); this is the value that is used in the next time step’s evaluation of carbon-climate feedbacks (e.g. CO\(_2\) fertilization of net primary productivity, surface ocean carbonate chemistry). In other words, an atmospheric CO\(_2\) constraint at time \(t\) does not affect carbon-climate feedbacks until \(t+1\).
The CO\(_2\) constraint need not span the entirety of the Hector simulation, or even be continuous. At any given time step, Hector will check whether or not a CO\(_2\) constraint exists at that time step and only apply the constraint if it is present. This means that “hybrid” runs are possible, where only some specific time ranges have CO\(_2\) constraints while others calculate the atmospheric carbon pool and CO\(_2\) concentrations according to Hector’s standard carbon cycle.
These all work in more-or-less the same way, and are similar to the atmospheric CO\(_2\) constraint (above), except that there is no equivalent to the carbon pool adjustment for these gases. In the input file, they are triggered by a line like the following in their corresponding component section:
CH4_constrain=csv:path/to/file.csvAs with other CSV inputs, the /path/to/file.csv above must have columns Date and CH4_constrain. Alternatively, constraints can be set from the R interface:
# library(hector)
# core <- newcore("/path/to/input/file.ini")
setvar(core, 1900:2000, CH4_CONSTRAIN(), 750, getunits(CH4_CONSTRAIN()))Constraints are applied as follows: At any given time step, Hector will check if the constraint has a value for that time step (e.g. CH4_constrain.exists(t)). If the constraint exists, Hector will skip all atmospheric chemistry calculates and set the corresponding atmospheric concentration value to the constraint value (e.g. CH4.set(t, CH4_constrain.get(t)). If the constraint does not exist, Hector will proceed with its standard atmospheric chemistry routines for calculating the atmospheric concentration based on emissions and concentrations of other relevant species. This means that concentration constraints always take precedence over emissions; in other words, if a particular time step has both emissions and a concentration constraint, the emissions are ignored.
Note that CH\(_4\) and N\(_2\)O have special variables for their pre-industrial concentration that could conflict with the constraint. In Hector, concentration constraints take precedence over pre-industrial concentrations; in other words, Hector assumes that if you provide a concentration constraint for the pre-industrial timestep, that is the concentration you want, regardless of the prescribed pre-industrial value.
Hector does not perform any interpolation of constraints – they are applied only in the exact years that they are provided by the user, and all other years are treated (including those immediately before or after constrained years) are treated as unconstrained (typically, emissions-driven). This means that constraints can abruptly force Hector’s climate system into state that is inconsistent with the previous time step. Concentrations for the first year of a constraint can be discontinuous compared to the previous year without a constraint. Concentrations after the last year of a constraint will not necessarily have a discontinuity, but the behavior of the corresponding component and any related components may change after this point. It is the user’s responsibility to make sure that constraints are continuous.