Multi-plant/species considerations

[Samuel-amap]

Listing future considerations and difficulties for simulations incorporating multiple plants. (API considerations and other prior discussions should probably go here as well, but I won't summarise them right now, leaving those for a future comment).

• The soil model might be worth extracting from the modellist/mapping as it depends on the location and charactestics external to the plant, and might be the same for all simulated plants. It makes sense for it to be distinct, and to be dropped in separately to the plant modellist in many cases.
• When more than two plants make use of an interaction model, the order in which the model runs might matter, as there is a three way dependency A+B, B+C, C+A. This hasn't been an issue with couplings and hard dependencies so far, they haven't exposed this problem yet (iirc).

Note : Examples of potential plant-plant interactions that might not use an intermediary medium / that aren't easily implemented as emergent behaviour from other models or implicit consequences of atmospheric/light interactions :

• Honeysuckle strangulation
• Roots fusing (would potentially change carbon allocation, for example)
• Young saplings growing in the same spot and fusing together

(Not unrelated : #114 )

[Samuel-amap]

MTG : multiple MTG ? Single scene root that branches out into multiple plants ?

Models : have a 'per-plant' trait ? Some models are plant-independent, some need to run per-plant. It might also make sense when moving to a multi-plant simulation to distinguish between models that are more or less internal to the plant and those that provide outputs to the world. A single 'black-box' node corresponding to the plant or its instance to the scene might keep internal complexities internal and only expose what is necessary.

Having distinct modellists/mappings per plant for a small amount of plants makes sense (and distinct ones for different species always makes sense), but might not be ideal for larger scenes. The approach used there drastically impacts potential variable name conflicts and handling.

[VEZY]

Point avec Samuel du 07/01/2024:

On peut faire des boîtes avec des mappings pour chaque espèce, et ensuite un meta-mapping qui prends ces boîtes.

Prenons en exemple une scène qui prends 2 plantes de palmier à huile, et un modèle biophysique qui tourne à l'échelle scène et qui prends les modèles biohysiques à l'échelle feuille de chaque plante en hard-dependency.

Le meta-mapping aurait ce format:

mtg = ... # This is the MTG with all nodes, including scene, both plants and the soil
palm1 = mtg[1]
palm2 = mtg[2]

metamapping= Dict(
    "Scene" => SceneEnergyBalance(),
    "Plant" => PlantMappings(
        1 => XPalm_Mapping(palm1) |> MultiScaleModel([:ftsw => "Soil"]),
        2 => XPalm_Mapping(palm2) |> MultiScaleModel([:ftsw => "Soil"]),
    ),
    "Soil" => FTSW(),
)

Note

We use the API proposed in #121 for providing the multiscale variables to the plant mappings (here, the ftsw). This has not yet been implemented, but it gives an idea of what it could look like.

In this example, the scene scale takes a model SceneEnergyBalance that takes as hard-dependency some models declared in the mapping of the plants. They will be removed from the dependency graph of the plants and branched as hard dependency children of the SceneEnergyBalance model that will run them manually (because it is an iterative computation).

Then we declare a plant scale that takes a PlantMappings, which lists the plants and their associated model mappings. The PlantMappings elements are given as a pair of values of plant number and plant mapping. The plant mapping is a standard mapping we define in PlantSimEngine. The mappings include all models that are plant-related, such as photosynthesis, carbon allocation, growth... But no model related to computations at other broader scales such as the soil water content, atmosphere or light interception. These ones are declared on the meta-mapping.

Note

We could use a struct for the mapping at the scale of the plant, sush as a PlantMapping? Related to #120 (but naming it PlantMapping instead of ModelMapping). And for the meta-mapping, we could say it is a SceneMapping?

What needs to be implemented should be pretty simple, as this proposition follows the current philosophy of the package. I think it boils down to two main things:

• We should add a way to run the models from a SceneMapping, running the models in the right order depending of their inputs/outputs. The plants would be runned sequentially, in the order that is provided by the user
• We should allow for cross-scales hard-dependency of models. For example the model for the energy balance of the scene would call the models at the leaves scale from the plants (these ones would be removed from the dependency graph of the plants)