Model orchestration

[tngTUDOR]

In our case, model orchestration is the means to make the different inputs and outputs of the models flow from one to the other.
This implies that the inter-dependencies between the are known and non-blocking.

• Is this a case for "meta-modeling" (i.e.: we need a different formalism to describe model interactions besides the model input and output specifications)?
• would regular modeling formalisms like UML or DEVS be sufficient and useful in this case, or do we start simply with ad-hoc model interaction DSL built by ourselves ?
• It seems evident that for scalability purposes, we must look from the begining at tools that enable data-pipelines that can handle large amounts of data to be handled. But not all models would be extracting and loading large volumes of data. In particular, it is foreseable that some initial collaborations/models shared from community members could have smaller sizes (in terms of data extraction and loading volumes). Would it make sense to keep separate model orchestration for such models, or do all models, regardless of data volumes they extract and load, have to use the same tooling/orchestration infrastructure?

[cmutel]

We need to have some criteria (objective or user-controlled) on how to choose between models when more than one is available. This becomes tricky where we either can't tell the difference in quality between them, or when they don't have the same coverage.

[shchoi839]

The idea is that model orchestrator will be responsible for keeping the mutation log of models executed (and who executed the model). From this mutation log, we can build a graph of model dependencies and also replay it.
For replayability, the database has to be immutable such that the execution can be for a specific time in the past.
Could you please give suggestions/improve on this comment @cmutel ?

[cmutel]

Sorry, should have asked this yesterday - what kinds of mutations do you expect to log here?

In my thinking, if we consider this chain:

flowchart LR
    fu["Functional unit"]
    A --> fu
    B --> A

Loading

And we label the models that produce A and B $m_{A}$ and $m_{B}$, respectively, then the order or operations would go:

• Functional unit is some amount of A
• Find the model which produces A
• Construct the demand object for A:

{
    'product': A_glossary_URI,
    'unit': kg_glossary_URI,
    'amount': 42,
    # Demand object can also have properties of product A which are more specific or different from the standard properties
    # The default spatiotemporal context is this year and global average
}

• Run the model $m_{A}$
• Receive a result from $m_{A}$

This result is something like:

{
    'demands': [demand_objects],
    'ecosphere': [ecosphere_flows],
    'meta': object  # Extra information about the model execution from the model itself
}

• Process the result and dispatch new model runs to satisfy the new demands (also includes a cut-off check)
• Add the ecosphere flows to the calculation result in preparation for LCIA
• Add the model run metadata to the calculation description log

Are you imagining mutations to the graph structure because we inject ancillary or generic models? Or maybe I am missing your point entirely?

[mklarmann]

The source code for the mutations we use, you find here: https://gitlab.com/eaternity/eos/-/tree/develop/core/core/graph_manager/mutations

[shchoi839]

@cmutel Sorry, I suppose the term "mutations" was not very well defined in my comment.

Using your first diagram as an example:
I was thinking that we would start from the "Functional Unit" node and log the demand for A as directly associated with the "Functional Unit" node. This will be a "mutation" in my description because we mutated the "Functional Unit" node from having unknown demand to a known demand. Though not entirely sure, I was thinking that the information that model A is what processes this demand would also be a part of the "edge-mutation" which adds an edge between "Functional Unit" and node "A".
Once we receive the results from model A, we would add the ecosphere flows and demands as a "mutation" that is associated with node "A"

I don't know if my explanation makes sense. Please let me know if some points are particularly unclear.

[YannickSchubert]

There are models where the result depends on the input (e.g. a Freezing Model might output various different frozen product depending on the input, frozen banana vs frozen strawberry vs frozen blueberry etc.). We don't want to have one separate model per output-product. But it might lead to complications for the question "Who produces the product?".

[mklarmann]

Group Middle.pdf