Multi-variant modeling

[Matthias776]

Is it possible to store multiple model variants, which make use of the same resources, within a single SSP to reduce the data size when exchanging models?

[arun3688]

@ if I understood your question ,You can just create one ssv resources at top level and store all the values of multiple models in a single ssv file, Do you mean this ?

[Matthias776]

When I'm setting up a new SSP right now I first need to create a system, add components and connect them with each other to be able to simulate it, so that I asked myself if it would be possible to save and load ssd files.
The advantage would be that multiple model variants can be saved within a single ssp and FMUs doesn't need to be saved multiple times.
The current alternative is to have one ssp for one model variant, if I understood right?

[arun3688]

@Matthias776 It is still not clear.,

so that I asked myself if it would be possible to save and load ssd files

Yes it is possible to save and import the ssd files, you should use

oms_export("model", "model1.ssp")
oms_importFile("model1.ssp")

you can import the ssp and do changes to the existing ssp and export it again

[Matthias776]

The feature was mentioned at the Modelica Conference

https://ssp-standard.org/publications/2018_American_Modelica_Conference/2018_Usermeeting_SSP-StatusandPlans.pdf

The idea is that multiple model structures can be stored in one SSP, so that it is not necessary to replace the entire ssp, but only to change the structure (referenceResource of ssd) stored within the ssp.

[arun3688]

@Matthias776 Ok now i understand what you want, I read the SSP specification and it is possible to bundle multiple ssd files in a single ssp. see below the ssp specification

Optionally the ZIP archive MAY contain multiple SSD file entries at root level, each with a different file 
name [ e.g. SystemStructure.ssd, VarA.ssd, VarB.ssd ]. This allows the bundling of multiple 
variants of a system structure definition referencing a similar set of packaged resources as one SSP.
There MUST still be one SSD file named SystemStructure.ssd at the root of the ZIP archive which is 
deemed to be the default variant. Tools not supporting variant-containing SSPs MUST deal with the 
given SSP by ignoring all contained SSD files except for the SystemStructure.ssd default file.

We don't have that feature as of now, But how would you like to have it ? My thoughts is we can do something like below

oms_importFile("model1.ssp") // SystemStructure.ssd will be used
oms_addResources("model", "var1.ssd") // to add the .ssd to resources folder 
// and then invent some new API()
oms_referenceSSD("SystemStructure.ssd", "var1.ssd", "SystemStructure_replace.ssd")
    arg1 - current `SystemStructure.ssd` 
    arg2-  ssd to be replaced and renamed as `SystemStructure.ssd` in the top level
    arg3 - rename and keep the SystemStructure.ssd in resources folder to be used later as multi variants
oms_export("model","model1.ssp")

You are welcome to give your suggestion

[Matthias776]

That would fit to my expectations as well. The challenge for the implementation of the function will be how components are stored and named when using them "multiple times".

[arun3688]

Yes that would be a challenge, the replacing ssd should have the same component name available in the resource folder, but that is tricky it might be possible the same fmu can have a different name in another ssd files and in such cases the users must be responsible to change the names according to existing component names and that can be done via extending oms_referenceResources(), currently only ssv and ssm are supported, we can extend this to switch the references with component names, i don't know or we have to invent a new API,

But if you do not care about the ssp size, then with oms_addResources() you can completely export all the components of one ssp to an existing ssp and then the component names are always synchronized when replacing the ssd, But we will discuss this internally when lennart comes back from his vacation.

But i guess when you replace the ssd, there should be API to change the fmu names according to the resources folder and the ssd must be updated when exporting

[arun3688]

@New Solution discussed with lennart

oms_import("A.ssp")
// new API
oms_listVariants("model") // lists all the ssd variants in the ssp (e.g. root, varA, varB) 
oms_activateVariant("model",  "varB")   // activates variantB , all changes will go to variant B 
oms_duplicateVariant("model, "varC" )   // create a new variant `varC` which is basically a new .ssd file which is a copy of varB (current active variant)

oms_duplicateVariant() , will allow OMSimulator to create multi variant modelling without no need to add an external resources in the current ssp file

An example

oms_newModel("model")
oms_addSystem("model.root", "system_wc")
oms_addSubModel("model.root.A", "A.fmu")
oms_setReal("model.root.A.param1", "10")
oms_duplicateVariant("model", "varB")
oms_addSubModel("model.root.B" ,"B.fmu")
oms_setReal("model.root.A.param2", "20")

oms_export("model", "variant.ssp")

Variant.ssp
    SystemStructure.ssd
    varB.ssd
    resources\
        A.fmu
        B.fmu

[arun3688]

@Matthias776 We are planning to implement it sooner, but we don't know how much time it can take but we will update you once it is completed

[arun3688]

@Matthias776 The export feature of multi variant modelling is implemented now with this commit e07f46c

here are some of the examples you can look

https://github.com/OpenModelica/OMSimulator/blob/master/testsuite/simulation/duplicateVariant1.lua
https://github.com/OpenModelica/OMSimulator/blob/master/testsuite/simulation/duplicateVariant2.lua
https://github.com/OpenModelica/OMSimulator/blob/master/testsuite/simulation/duplicateVariant3.lua

[Matthias776]

Great news! When are you going to roll out the update for Python? Currently there is still version 2.1.1.post157 available which doesn't contain the new features.

[arun3688]

@Matthias776 , The python variant is already available in the latest master with this commit https://github.com/OpenModelica/OMSimulator/commit/6b31ed54854f5616153f5d16f20a877c88c8af99, Please pull the latest master from git, An example of python script
https://github.com/OpenModelica/OMSimulator/blob/master/testsuite/simulation/duplicateVariant4.py

[arun3688]

@Matthias776 the implementation of full support to multi variant is completed in OMSimulator with this commit a6ca0ee, A full python example on how to create a multi variant ssp and activate the different variants is available here https://github.com/OpenModelica/OMSimulator/blob/master/testsuite/simulation/duplicateActivateVariant2.py

@robha67 Hi robert this is a very nice feature implemented in OMSimulator, now you don't need to use exportSSVTemplate and configure different ssv configurations for different start values using oms_referenceResources API, with multi-variant modelling you can achieve the different configurations of same model without much complication, refer the above example. The main idea is you can have multiple ssd files with different start values for the same models in a single ssp file.