Silent errors for wrong mapping

[VEZY]

If we provide a wrong mapping, we don't necessarily return an error, and even worse, we may mutate the wrong variable.

I found this issue when implementing the LeafGeometryModel in XPalm. You can reproduce it using the following mapping instead of the one we have now:

MultiScaleModel(
    model=VPalm.LeafGeometryModel(
        mtg=p.mtg,
        rng=Random.MersenneTwister(p.parameters["vpalm"]["seed"]),
        vpalm_parameters=p.parameters["vpalm"]
    ),
    mapped_variables=[
        :graph_node_count => "Scene" => :graph_node_count,
        :height_internodes => "Internode" => :height,
        :radius_internodes => "Internode" => :radius,
        :biomass_leaves => "Leaf" => :biomass,
        :rank_leaves => "Leaf" => :rank,
    ],
),

For reference, we currently have:

MultiScaleModel(
    model=VPalm.LeafGeometryModel(
        mtg=p.mtg,
        rng=Random.MersenneTwister(p.parameters["vpalm"]["seed"]),
        vpalm_parameters=p.parameters["vpalm"]
    ),
    mapped_variables=[
        :graph_node_count => "Scene" => :graph_node_count,
        :height_internodes => ["Internode" => :height],
        :radius_internodes => ["Internode" => :radius],
        :biomass_leaves => ["Leaf" => :biomass],
        :rank_leaves => ["Leaf" => :rank],
    ],
),

Notice how we wrongly define the mapping for the internodes and leaves, as if we expected a single node out of them. The result is that we get a leaf biomass that is very high, always increasing. This is very bad as we silently change the wrong variable...

[VEZY]

Hmm, XPalm is using check=false by default... I'll have to check that again with check=true before closing this issue, just to be sure.

[Samuel-amap]

I reproduce the issue with check=true on the main branch

[Samuel-amap]

Relates to #159, and also to the issue about iteratively creating modellists, and API ambiguity (which impact the likelihood of such bugs appearing).

Getting a MWE failure case and adding it to the corner-cases testset would be a good idea.

It is not possible to detect every situation with the current way of building the mapping, not without extra user input for sanity checks : an organ might be initially absent, or only have one instance, and be expected to have at most one instance, which would make both syntaxes valid. In situations where it is expected to have multiple instances, however, or already has multiple instances at the beginning of the simulation, it is possible to diagnose the error unambiguously when the graph is created.