-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Some models have variables that are inputs and outputs (they update the value of a variable). The current recommendation is to change the variable name and create a new variable as output; for example, carbon_offer as input becomes carbon_offer_after_rm as output.
It could still be nice to define a way to update the value of a variable. The issue is that we don't really know how to compute the dependency graph if we have several models that update the value of a variable, especially when we have several scales in the simulation (we can't use the order on which the models appear because it also depends on the scales).
What I propose is an explicit way in the mapping to define which model is used as input for the variable that is updated, and then PlantSimEngine would treat the updating model as the one that gives the output variable. For exemple:
mapping = Dict(
"Plant" => (
FirstModelBiomassOutput(),
MultiScaleModel(
model=SecondModelBiomassUpdate(),
mapping=[:biomass => FirstModelBiomassOutput,]
),
FirstModelBiomassInput(),
),
"Leaf" => (
MultiScaleModel(
model=ThirdModelBiomassUpdate(),
mapping=[:biomass => "Plant" => SecondModelBiomassUpdate,],
),
),
)The first model at plant scale FirstModelBiomassOutput computes the biomass, it is an output of the model.
The second model at plant scale SecondModelBiomassUpdate updates the biomass, it uses the variable as an input and an output of the model. The biomass is taken from FirstModelBiomassOutput (declared in the mapping).
The third model at leaf scale ThirdModelBiomassUpdate also updates the biomass at plant scale, it uses the variable as an input and an output of the model. The biomass is taken from SecondModelBiomassUpdate (declared in the mapping).
The last model, FirstModelBiomassInput(), takes the biomass as an input. It will be computed last because the previous ones are direct children from one another.
We have everything we need to compute the dependency graph, and it would look like this:
FirstModelBiomassOutput -> SecondModelBiomassUpdate -> ThirdModelBiomassUpdate -> FirstModelBiomassInput
In summary, it is a way for the user to declare explicitly a part of the dependency graph.