Refer to variables in simulation environment (i.e. path to an FMU) that is removed when fully expanded

[CThuleHansen]

A MaBL specification that has yet to be fully expanded should be able to refer to variables located within the simulation environment.

Purpose

Consider a DSE experiment where many co-simulations will execute with the same master algorithm and changes will be isolated to values of parameters. In such a case it would be a waste to go through the entire process of generating a new specification every time. Instead, it should be possible to refer to variables located within an accompanying simulation environment file.

Usage

The simulation environment will be expressed in JSON.

Example

a simulation environment file might have a parameter defined as:

"parameterA": 5

The json file for parameters of initialization is then:

"parameters": {
         "{crtl}.crtlInstance.maxlevel": {"type": "reference", "value": "parameterA"}
       }

And the usage of such a parameter in MaBL is:

$parameterA$

So the pieces of creating a mabl specification is covered by the following (not necessarily in order)

1. Create Specification With References - Creates a MaBL specification WITH references to simulation environment variables, if any simulation environment variables are specified.
2. Create Specification - Creates a MaBL Specification WITHOUT reference to simulation environment variables, i.e. fully expanded
3. Expand References(simulation enviroment) - Replaces all simulation environment references with the related value
4. Type check - Type checks a MaBL specification. Simulation Environment Variables are not subject to typechecking and are expected to be correct.
5. Execute Specification - Executes a fully expanded specification. The result includes the specification of the simulation conducted.
6. Execute Specification(simulation environment) - Executes a specification and looks up a given value upon encountering any simulation environment references. The result of such a simulation contains the spec to be executed along with a simulation environment in order to get the full picture.

Notes

• Possibly skip: Execute Specification(simulation environment) as expandReferences can be executed just prior to execution.
• Possibly skip: Create Specification With References as this is default behaviour, and a fully expanded spec can be acquired by Expand References(simulation environment). However, some plugins might have custom behaviour that does not allow references, as the values have to be available up front to decide on the correct algorithm.

Help

@prasadtalasila and @lausdahl

• Feedback on syntax ($reference$)
• Feedback on configuration and json format. How can we create this in a nice fashion? I am leaning replacing the current parameters configuration of the initialization plugin from: "{crtl}.crtlInstance.maxlevel": 5 to "{crtl}.crtlInstance.maxlevel": {"type": "raw", "value": 5} and for references "{crtl}.crtlInstance.maxlevel": {"type": "reference", "value": "parameterA"}

[lausdahl]

I'm ok with any encoding in the simulation env and config. This is most likely going to be implemented in another tool. As long as the reference is defined it should be possible to type check it.

Full expansion is trivial. No references is left.

Expand to system environment variables. This is probable more interesting concerning DSE. It should be expanded like the full expansion but with a ENV devaluation to the correct type for each usage. Or optimised for a single ENV lookup and conversion and use of a variable but semantically it will be the same.

[CThuleHansen]

The first step of this is to support variables in runtime modules and not in a MaBL specification module yet. Thus, a runtime module can look up a variable in an accompanying environment file.