Serving multiple models from the same dataset

[spine-o-bot]

In GitLab by @jkiviluo on Jul 6, 2020, 13:00

From the start, the intention of Toolbox has been to serve multiple models. They can be of different uses (e.g. a scheduling model and a frequency stability model) or just 'competing' models (e.g. PLEXOS and SpineOpt) that different modelling groups use. There are several ongoing projects and projects in the pipeline that plan to use Spine Toolbox for these purposes - especially projects where 'competing' models would be compared.

First, for reference:

• Discussion about how to serve multiple models resurfaced here: https://gitlab.vtt.fi/spine/model/-/issues/177#note_17070
• Older reference how to serve different models: https://gitlab.vtt.fi/spine/model/-/issues/26
• There must be more especially in separate files early in the project. We did discuss quite a lot about archetypes/features/methods and that discussion is mostly relevant also for model discussion. Archetypes and models are entities of similar character. Feature/method as relationships or as parameters: https://gitlab.vtt.fi/spine/model/-/issues/69

Currently, Toolbox does not really allow serving multiple models without extensive scripting for each model. Furthermore, we don't have a way to tell what methods a specific model should use in a selected scenario for a specific entity. I've been mulling over these for quite some time and also discussed it with Per before he departed. I know there can be other views how to do this, but please give this proposal serious consideration - I've thought about it a lot from the perspective of making Toolbox really useful for a wide range of users. For that it needs to be flexible, but yet have a clear separation what different things do.

A fundamental thing that emerged is to keep scenario/alternatives as a separate layer of flexibility that is used for creating scenarios only. They shouldn't be used to define model specific functionality. This is bit tricky, since they can be used to change model functionality between scenarios. We just shouldn't 'overload' scenarios with additional Toolbox functionality. In other words, we should be able to define a model without scenarios (everything is using 'base' alternative). And then we should be able to define a selection from the same dataset for another model also without using scenarios (again, everything is using 'base' alternative, but partially different choices for what data is sent to this model). Furthermore, there should be a link between methods and the model - what methods a particular model is capable of using for a particular entity class.

I've been developing these ideas with a Powerpoint - it would have been nicer if I had a web-based drawing. But here is the link to the file where I try to make a plan (in G-Drive WP2 Data Structure folder):
https://drive.google.com/file/d/1D4My6O8E2GrUkrLrnq9heunBvmZyCCRo/view?usp=sharing

To be clear, that's not an implementation plan. It's a design and there are many choices to be made after that and of course to alter that. Among others, we should think whether models should be a special entity type. What to do about features and methods - it may be restricting to have them only as parameter values. If feature/methods become entities, should they have an entity type of their own or are they something more special like scenarios/alternatives (that choice should depend on whether they have enough common with entities that they would benefit from entity functionality).