ParameterBindings at a higher hierarchy level must take precedence over bindings defined in lower levels

[GorbadPS3]

Description

In the documentation for SSP, section 5.2.3 ParameterBindings, we can see the following definition:

When ParameterBinding sources on multiple levels of the hierarchy supply values for the same parameter, bindings at a higher hierarchy level take precedence over lower levels, i.e. bindings at a system level take precedence over bindings at a sub-system or component level

This means that in an SSP file, where we define a system like this:

<ssd:System
    name="Root">
    <ssd:ParameterBindings>
      <ssd:ParameterBinding>
	    <ssd:ParameterValues>
              <ssv:ParameterSet version="1.0" name="parameters">
                <ssv:Parameters>
                  <ssv:Parameter
                    name="A.width">
                    <ssv:Real
                      value="60"
                      unit="s" />
                  </ssv:Parameter>
                </ssv:Parameters>
              </ssv:ParameterSet>
            </ssd:ParameterValues>
      </ssd:ParameterBinding>
    </ssd:ParameterBindings>
    <ssd:Elements>
      <ssd:Component
        name="A"
        <ssd:ParameterBindings>
          <ssd:ParameterBinding>
            <ssd:ParameterValues>
              <ssv:ParameterSet
                version="1.0"
                name="parameters">
                <ssv:Parameters>
                  <ssv:Parameter
                    name="width">
                    <ssv:Real
                      value="30"
                      unit="s" />
                  </ssv:Parameter>
                </ssv:Parameters>
              </ssv:ParameterSet>
            </ssd:ParameterValues>
          </ssd:ParameterBinding>
        </ssd:ParameterBindings>
      </ssd:Component>
      <ssd:Component

Then, during OMSimulations, we should write the parameter value 60 to the parameter "width" of the sub-element "A".

This does not appears to be the case during my tests. If I remove the parameter definition from the sub-element "A", then I get different simulation results than if the parameter definition is there. Meaning, the sub-element's "width=30" is being applied to the component during simulations.

Steps to reproduce the behavior

Create an SSP model with a System hierarchy such that you're writing as a component level a parameter X, and above the component (in the system level) you're overriding it using the "Component.X" hierarchy reference mechanism.

Expected behavior

The parameters at the top level should be applied during simulaiton, not lower levels.

Version and OS

• Version: OMSimulator v2.1.1.post247-g614c663-mingw-notlm-debug
• OS: Win11, 64-bit

[arun3688]

@GorbadPS3 can you provide the ssp file, so that it is much easier to debug

[GorbadPS3]

@arun3688 Unfortunately, the SSP model used and all the sub-FMI components is proprietary. It should be enough to create a simple FMI model and create a single parameter for it, then define an output variable in the FMI that simply returns the parameter value. This way, you can then add this FMI as a component under a system in SSP, and define ParameterBindings as System and Component level to write to the same parameter. This should demonstrate the issue.

[arun3688]

@GorbadPS3 The name of the parameter at higher level and at component level should be the same, so the parameter binding at the component level should be written as full qualified names incase you want the system level hierarchy to take precedence over component level so it should A.width see below

    <ssd:Elements>
      <ssd:Component
        name="A"
        <ssd:ParameterBindings>
          <ssd:ParameterBinding>
            <ssd:ParameterValues>
              <ssv:ParameterSet
                version="1.0"
                name="parameters">
                <ssv:Parameters>
                  <ssv:Parameter
                    name="A.width">
                    <ssv:Real
                      value="30"
                      unit="s" />
                  </ssv:Parameter>
                </ssv:Parameters>
              </ssv:ParameterSet>
            </ssd:ParameterValues>
          </ssd:ParameterBinding>
        </ssd:ParameterBindings>
      </ssd:Component>

[GorbadPS3]

@arun3688 is this specified in the SSP standard? I cannot find a reference for why the individual Component's parameter should reference the whole system hierarchy like that. Why should the "Component" layer know about its position within the full system, by essentially "referencing upwards until you hit the root"?

[arun3688]

@GorbadPS3 I guess it is not specified in the standards but the example you have inline parameter bindings, and the component itself has another inline parameter settings which is fine, but you want the top level system parameter bindings to override the value and currently OMSimulator does not check for the inline settings in the ssp i guess i need to verify it. But we had discussion about this when we were implementing this and we thought that if we want to make system level parameter settings to take priority then it should be exported to ssv files and referenced in the ssp file for example

 <ssd:ParameterBindings>
          <ssd:ParameterBinding
          source="resources/import_export_parameters.ssv" />
</ssd:ParameterBindings>

and in the ssv file you can have all the top level parameter settings and it should work, see some examples we have

https://github.com/OpenModelica/OMSimulator/blob/master/testsuite/simulation/import_export_parameters1.lua
which exactly has the scenario, but also the ssp standard also little confusing and they have the following lines as well

More than one ParameterBinding can be supplied., In this case all of the parameters found will be 
used to parametrize the component, with parameter values in ParameterBinding sources appearing at 
a succeeding position in the element order taking priority over prior sources at the same hierarchy level, 
should a parameter be included in more than one ParameterBinding source

But anyways OMSimulator always checks for fully Qualified names in case for top level parameter priority like A.width, but this can be implemented to check with fully Qualified names

[GorbadPS3]

Using a source file ".ssv" does not seem to override inline variables in OMSimulator right now.

 <ssd:ParameterBindings>
          <ssd:ParameterBinding
          source="resources/import_export_parameters.ssv" />
</ssd:ParameterBindings>

^This, with this content:

<?xml version="1.0"?>
<ssv:ParameterSet
  xmlns:ssc="http://ssp-standard.org/SSP1/SystemStructureCommon"
  xmlns:ssv="http://ssp-standard.org/SSP1/SystemStructureParameterValues"
  version="1.0"
  name="From Separate File">
        <ssv:Parameters>
                <ssv:Parameter
                    name="A.width">   (NOTE: Trying "width" only here doesn't work either)
                    <ssv:Real
                      value="40"
                      unit="s" />
                  </ssv:Parameter>
        </ssv:Parameters>
</ssv:ParameterSet>

Does not affect my simulation results at all, if my SSP has this definition:

    <ssd:Elements>
      <ssd:Component
        name="A"
        <ssd:ParameterBindings>
          <ssd:ParameterBinding>
            <ssd:ParameterValues>
              <ssv:ParameterSet
                version="1.0"
                name="parameters">
                <ssv:Parameters>
                  <ssv:Parameter
                    name="width">    (NOTE: Trying "A.width" here doesn't work either)
                    <ssv:Real
                      value="30"
                      unit="s" />
                  </ssv:Parameter>
                </ssv:Parameters>
              </ssv:ParameterSet>
            </ssd:ParameterValues>
          </ssd:ParameterBinding>
        </ssd:ParameterBindings>
      </ssd:Component>

In other words, it doesn't matter if my inline parameter is written as "A.width" (full path) or "width" (just variable name), the .ssv file does not override it. Is this intended behaviour in OMSimulator?

The way I see it: It would be useful for an SSP to have "sane default values" in the inline parameters, but from the .ssv file you can then override what you need to create a case-specific initial condition for your system. This doesn't seem to be a supported use-case?

I can confirm that removing the inline definition entirely does allow me to modify the parameter values of components, using an SSV file that looks like this (i.e. contains full path "A.width"):

<?xml version="1.0"?>
<ssv:ParameterSet
  xmlns:ssc="http://ssp-standard.org/SSP1/SystemStructureCommon"
  xmlns:ssv="http://ssp-standard.org/SSP1/SystemStructureParameterValues"
  version="1.0"
  name="From Separate File">
        <ssv:Parameters>
                <ssv:Parameter
                    name="A.width">
                    <ssv:Real
                      value="40"
                      unit="s" />
                  </ssv:Parameter>
        </ssv:Parameters>
</ssv:ParameterSet>

[arun3688]

@GorbadPS3 I did some testing and i can confirm the following
case 1
If you supply parameter bindings both at component level and also at system level, then the parameter binding at component level is applied and the system level parameter bindings are ignored which should not be the case, see the following ssp
system2.zip

case 2
If you supply parameter bindings at top level system, then the parameter binding at system level is applied to component see the following ssp
system.zip

OMSimulator currently checks for the parameter bindings at the current level and if there are no parameter bindings exists then it checks for the top level systems and the values are applied (case-2), however according to ssp standards the top level system parameter bindings have priority over component level, I will try to fix this

[arun3688]

@GorbadPS3 the issue is fixed with this commit 637a1c9, please update your OMSimulator and hopefully it should fix the issue

[GorbadPS3]

@arun3688 Sorry for the delayed response. I've been extremely busy at work, and will look into this as soon as I have time. Thank you for the quick fix!