MSMI needs variable groups containing variable groups #526

ljamt · 2020-02-13T07:58:26Z

To enable bonds, we need to support variable groups containing variable groups. The <VariableGroupContainments> is proposed by WP2 as shown in the following example:

<OspModelDescription>
        <VariableGroups>
            <VariableGroup type="A" name="A">
                <Variable name="V1"/>
            </VariableGroup>
            <VariableGroup type="B" name="B">
                <Variable name="V2"/>
                <Variable name="V3"/>
            </VariableGroup>
            <VariableGroup type="C" name="C">
                <Variable name="V4"/>
                <Variable name="V5"/>
            </VariableGroup>
        </VariableGroups>

        <VariableGroupContainments>
            <VariableGroupContainment group="A" contains="B"/>
            <VariableGroupContainment group="A" contains="C"/>
        </VariableGroupContainments>
    </OspModelDescription>

We have briefly discussed this before. Can we agree on the format? Is it ok?

The text was updated successfully, but these errors were encountered:

lassebje · 2020-02-13T08:30:51Z

I might misunderstand this, but since does not have a name is seems it is only possible to have one containment hierarchy. If that is the case, I would prefer the syntax to be more explicit. Meaning VariableGroup B and C should actually recide within VariableGroup A => VariableGroupContainments element can be removed

ljamt · 2020-02-13T08:52:39Z

I might misunderstand this, but since does not have a name is seems it is only possible to have one containment hierarchy. If that is the case, I would prefer the syntax to be more explicit. Meaning VariableGroup B and C should actually recide within VariableGroup A => VariableGroupContainments element can be removed

This has been discussion. If I remember correctly we need to solve having variable group B and C to be used on its own, and to be part of potentially several nested variable groups. @mrindar, have I understood the MSMI needs correctly here? Or can we do as @lassebje suggests:

<VariableGroups>
    <VariableGroup type="A" name="A">
        <Variable name="V1"/>
        <VariableGroup type="B" name="B">
            <Variable name="V2"/>
            <Variable name="V3"/>
        </VariableGroup>
        <VariableGroup type="C" name="C">
            <Variable name="V4"/>
            <Variable name="V5"/>
        </VariableGroup>
    </VariableGroup>
</VariableGroups>

mrindar · 2020-02-13T08:55:57Z

There are three reasons for this format:

To reduce the amount of potentially nested elements in the XML file
To enable using contained variable groups in connections outside of the containment. For the example shown by @ljamt, this would mean that variable group C could be used in a connection on it's own.
Having all variable groups defined 'at the top' makes it easier to reach/find them

mrindar · 2020-02-13T09:03:44Z

I might misunderstand this, but since does not have a name is seems it is only possible to have one containment hierarchy. If that is the case, I would prefer the syntax to be more explicit. Meaning VariableGroup B and C should actually recide within VariableGroup A => VariableGroupContainments element can be removed

This has been discussion. If I remember correctly we need to solve having variable group B and C to be used on its own, and to be part of potentially several nested variable groups. @mrindar, have I understood the MSMI needs correctly here? Or can we do as @lassebje suggests:
<VariableGroups>
    <VariableGroup type="A" name="A">
        <Variable name="V1"/>
        <VariableGroup type="B" name="B">
            <Variable name="V2"/>
            <Variable name="V3"/>
        </VariableGroup>
        <VariableGroup type="C" name="C">
            <Variable name="V4"/>
            <Variable name="V5"/>
        </VariableGroup>
    </VariableGroup>
</VariableGroups>

You replied while I was typing :)

I think I should retract my previous comment, because semantically there is no difference between these two formats, they represent the exact same information. However, I believe it will be easier to parse/generate this file with the 'flat' format.

mrindar · 2020-02-13T09:12:52Z

Actually, a variable group containing only outputs could be contained within several variable groups, which would make the 'nested' format quite messy. Probably not a very realistic scenario though.

ljamt · 2020-02-13T10:03:26Z

Actually, a variable group containing only outputs could be contained within several variable groups, which would make the 'nested' format quite messy. Probably not a very realistic scenario though.

This is what I meant. In this case we'll repeat the same variable group in several hierarchies as variable group B is repeated in this example:

<VariableGroups>
    <VariableGroup type="AA" name="AA">
        <Variable name="V1"/>
        <VariableGroup type="B" name="B">
            <Variable name="V2"/>
            <Variable name="V3"/>
        </VariableGroup>        
    </VariableGroup>
    <VariableGroup type="BB" name="BB">
        <Variable name="V2"/>
        <VariableGroup type="B" name="B">
            <Variable name="V2"/>
            <Variable name="V3"/>
        </VariableGroup>
    </VariableGroup>
</VariableGroups>

ljamt · 2020-02-13T10:15:12Z

I might be terribly wrong here, just thinking loud. Can we keep it flat and still explicit by referring to elements?

<VariableGroups>
    <VariableGroup type="A" name="A">
        <Variable name="V1"/>
        <Variable name="V2"/>
    </VariableGroup>
    <VariableGroup type="B" name="B">
        <Variable name="V3"/>
        <Variable name="V4"/>
    </VariableGroup>
    <VariableGroup type="C" name="C">
        <Variable name="V5"/>
        <VariableGroupRef name="A"/>          <-----
        <VariableGroupRef name="B"/>          <-----
    </VariableGroup>
</VariableGroups>

lassebje · 2020-02-13T10:36:49Z

In response to parsing: This is the computers job, and is "easy" ;).
From a human point of view the nested element is more intuitive and you do not need to match them afterwards => easier for "the computer" as well.

As long as the naming is unique, it does not matter if is flat or nested either. Hence the VariableGroupContainments as it stand only adds to the complexity in my opinion.
We can also live with duplicating some of the variables when used in different variable group "scenarios" I think.

Here is an example of a hypothetical system

<VariableGroup type="body" name="vessel">
	<VariableGroup type="position" name="myPos">
		<Variable name="x"/>
		<Variable name="y"/>
		<Variable name="z"/>
		<Variable name="rx"/>
		<Variable name="ry"/>
		<Variable name="rz"/>
	</VariableGroup>
	<VariableGroup type="velocity" name="myVel">
		<Variable name="vx"/>
		<Variable name="vy"/>
		<Variable name="vz"/>
		<Variable name="avx"/>
		<Variable name="avy"/>
		<Variable name="avz"/>
	</VariableGroup>
	<VariableGroup type="acceleration" name="myAcc">
		<Variable name="ax"/>
		<Variable name="ay"/>
		<Variable name="az"/>
		<Variable name="aax"/>
		<Variable name="aay"/>
		<Variable name="aaz"/>
	</VariableGroup>
	<VariableGroup type="forceInput" name="myForce">
		<VariableGroup type="force" name="f1">
			<Variable name="fx"/>
			<Variable name="fy"/>
			<Variable name="fz"/>
		</VariableGroup>
		<VariableGroup type="moment" name="myMoment">
			<Variable name="mx"/>
			<Variable name="my"/>
			<Variable name="mz"/>
		</VariableGroup>
		<VariableGroup type="point" name="offset">
			<Variable name="foffsetx"/>
			<Variable name="foffsety"/>
			<Variable name="foffsetz"/>
		</VariableGroup>
   </VariableGroup>
</VariableGroup>

lassebje · 2020-02-13T10:37:34Z

We should also think about frame of reference here in my opinion. One example could be

lassebje · 2020-02-13T10:41:48Z

It seems my frame-xml example crashed the renderer..
frame.txt

ljamt · 2020-02-13T14:58:03Z

The hypothetical vessel system from @lassebje looks nice and clean with nested VariableGroups. How does it fit with the MSMI thoughts @mrindar?

Wonder how this plays out in cse-core if we allow connecting any sub tree variable group of a nested variable group..

mrindar · 2020-02-13T15:22:18Z

We definitely need to discuss how to represent reference frames, but let's not do it in this issue, please. I suggest that you open a new issue with your example and then "version 2.0" of OspModelDescription.xml can include reference frame stuff.

I'll attempt to summarize what we are trying to represent and achieve for reference:

OspModelDescription defines VariableGroups and UnitDefinitions
VariableGroup:
- Has a name
  - Must be unique within a given OspModelDescription
- Has a type
  - This is a finite pre-defined set (force, velocity, etc.)
- Has a list of Variables
- Has a nested list of VariableGroups
  - This is unbounded
- VariableGroups containing only output Variables (recursively through all nested VariableGroups) can be used in several connections.
- VariableGroups containing at least one input Variable can only be used in one connection
- A VariableGroup can be used in a connection even if it is nested inside another VariableGroup, as long as the causality- and type jazz is up to code.
Variable
- Has a name
  - Must match variable name in modelDescription.xml
- Has a causality and data_type
  - From the msmi-validator's point of view, this information could (and probably will) be retrieved from the modelDescription.xml, so not strictly required here, but I think we would like to explicitly state it here for cse-core
- Has a unit
  - If specified, must refer to a UnitDefinition defined inside OspModelDescription.xml
  - If not specified, and FMI version 2.0, use the unit and UnitDefinition defined in the modelDescription.xml (if it is defined there)
- Belongs to a VariableGroup
  - Output variables can exist in many variable groups
  - Input variables can exist in only 1 variable group
UnitDefinitions
- Using fmi2Unit.xsd for the definition of units
- Referred to by Variables

The OspModelDescription.xsd is not expected to validate/verify everything stated above

As a consumer of OspModelDescription.xml my expectations are:

I can retrieve the related modelDescription.xml (I know this isn't specified inside OspModelDescription.xml, but I suppose we have some convention that the OspModelDescription.xml lives inside- or parallell to the .fmu. Either way, I expect some systematic way of being able to reach the correct modelDescription.xml)
I can get all UnitDefinitions
I can get all VariableGroups
I can get all Variables and all VariableGroups contained within a given VariableGroup
???
Profit

I would like to achieve this without having to 'jump through to many hoops' (i.e. the format isn't unecessarily cumbersome and complex).

I'm totally fine with @lassebje's suggestion so let's just get cracking. Do you guys want to change the .xsd @ljamt, or should I just do it?

lassebje · 2020-02-13T17:45:34Z

👍I totally agree on keeping reference frames out for now. I will try to controll my hang-up on them 😉 @ljamt Should cse-core really know about composite groups or even groups at all? We can just flatten this structure in the bottom layer I assume.

ljamt · 2020-02-13T21:23:57Z

Do you guys want to change the .xsd @ljamt, or should I just do it?

Please go ahead @mrindar :) Good to settle this revision of the schema. However, it’ll take some more effort to support parsing it.

Should cse-core really know about composite groups or even groups at all?

Only the in memory representation of the configuration. Not during simulation.

…ModelDescription.xsd

* #526: New OspModelDescription.xsd version * newline at end of file * #526 aligning example x_OspModelDescription.xml's to mach updated OspModelDescription.xsd Co-authored-by: ljamt <[email protected]>

ljamt added question Further information is requested discussion needed Let's have a discussion about this urgent blocking issue feature request labels Feb 13, 2020

mrindar self-assigned this Feb 14, 2020

mrindar added a commit that referenced this issue Feb 24, 2020

#526: New OspModelDescription.xsd version

663f281

ljamt pushed a commit that referenced this issue Feb 28, 2020

#526 aligning example x_OspModelDescription.xml's to mach updated Osp…

2ce8030

…ModelDescription.xsd

ljamt linked a pull request Feb 28, 2020 that will close this issue

#526: New OspModelDescription.xsd version #530

Merged

mrindar closed this as completed in #530 Mar 4, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSMI needs variable groups containing variable groups #526

MSMI needs variable groups containing variable groups #526

ljamt commented Feb 13, 2020

lassebje commented Feb 13, 2020

ljamt commented Feb 13, 2020

mrindar commented Feb 13, 2020

mrindar commented Feb 13, 2020 •

edited

Loading

mrindar commented Feb 13, 2020

ljamt commented Feb 13, 2020

ljamt commented Feb 13, 2020

lassebje commented Feb 13, 2020 •

edited

Loading

lassebje commented Feb 13, 2020

lassebje commented Feb 13, 2020 •

edited

Loading

ljamt commented Feb 13, 2020

mrindar commented Feb 13, 2020

lassebje commented Feb 13, 2020

ljamt commented Feb 13, 2020

MSMI needs variable groups containing variable groups #526

MSMI needs variable groups containing variable groups #526

Comments

ljamt commented Feb 13, 2020

lassebje commented Feb 13, 2020

ljamt commented Feb 13, 2020

mrindar commented Feb 13, 2020

mrindar commented Feb 13, 2020 • edited Loading

mrindar commented Feb 13, 2020

ljamt commented Feb 13, 2020

ljamt commented Feb 13, 2020

lassebje commented Feb 13, 2020 • edited Loading

lassebje commented Feb 13, 2020

lassebje commented Feb 13, 2020 • edited Loading

ljamt commented Feb 13, 2020

mrindar commented Feb 13, 2020

lassebje commented Feb 13, 2020

ljamt commented Feb 13, 2020

mrindar commented Feb 13, 2020 •

edited

Loading

lassebje commented Feb 13, 2020 •

edited

Loading

lassebje commented Feb 13, 2020 •

edited

Loading