Set up a 'bounds' class that sets up reasonable limits for sensitivity test (in the future)

[vgro]

During our group meeting today, we were discussing how we define 'success' of the virtual rainforest. One part of our answer was that we want the model to produce reasonable outputs (from a physical and ecological point of view) when given a reasonable range of inputs, for example observations plus inter-annual variability/future projections or data from different locations (e.g. Amazon vs Borneo).

Our idea to implement this was to set up a 'bounds' class that allows the user to sets up reasonable limits. These can be absolute values or relative (eg plus or minus x percent of target). The virtual rainforest could then be run in 'bound-checking' mode; or 'bound-imposed' mode as a kind of sensitivity test.

This is definitely something to consider much further down the line, but we wanted to bring it up as a discussion now to have it documented/discussed alongside the main code development.

[dalonsoa]

I think that a first milestone for any simulation tool is if it can predict the past: pick the initial conditions somewhere in the past (recent enough so you have enough data) and see how well you can predict its future until the present time. If it goes totally wrong, then you will need to refine the model somehow. Trying to forecast our own future makes pretty hard to decide if the prediction is reasonable.

[davidorme]

As a mechanism, we could have something optional within the timing loop that takes variable names and bounds and then checks the data instance when the loop has updated models. Something like:

data.bounds_check(check_vars: list[tuple[str, float, float]], warn_not_fail=True)

And then part of the configuration might include a check bounds section that can be used to define what is being checked in a particular run and what action should be taken.

[[data.check_bounds]]
var_name = 'air_temperature'
lower_bound = -20
upper_bound = 100

As long as the variables being checked are being stored in that data object (so not potential model internal variables), we can then provide some simple toml files for default bounds checking which users can extend or make more or less exacting in a flexible way.