When running

java -jar osp-cli.jar -fmu path/to/model.fmu

or

java -jar osp-cli.jar -file path/to/model_OspModelDescription.xml

I get error messages like the following:

Exception in thread "main" java.lang.NullPointerException
        at java.io.File.<init>(File.java:277)
        at com.opensimulationplatform.cli.Main.main(Main.java:85)

Presumably, the error occurs because both the -fmu and -file switches are mandatory, but the message does not indicate this. (Furthermore, IMO, a NullPointerException always represents a bug in the program, never a usage error.)

Also note that the mandatoriness of the options is not specified in the built-in usage documentation, so it's hard for a user to tell. (They're listed as "options", which at least seems to hint that they might be optional.)

We need a way to describe and validate special connections like:

• Sum connection (target = sum of sources)
• Transforms and rotations
• Linear transforms (y = ax + b) for e.g. unit conversions

The format in cse-config.json could be something like:

"specialConnections": [
    {
      "type": "sum",
      "sources": [
        {
          "simulator": "Thruster1",
          "plug": "Force"
        },
        {
          "simulator": "Thruster2",
          "plug": "Force"
        }
      ],
      "targets": [
        {
          "simulator": "Hull",
          "socket": "ThrusterForces"
        }
      ]
    }
  ]

This example may however be too generic in order to properly describe a transform etc.

When validating a OspModelDescription file defining a variable that does not exist in the FMU's modelDescription, the output is a java exception. I think the output should be a message explicitly telling what is wrong. For instance: Variable: A used in Variable Group: Group A, is not defined in modelDescription.xml of FMU: FMU A

The exception is shown below:

Exception in thread "main" java.lang.NullPointerException at com.opensimulationplatform.core.owlbuilder.VariableGroupOwlBuilder.setVariables(VariableGroupOwlBuilder.java:185) at com.opensimulationplatform.core.owlbuilder.VariableGroupOwlBuilder.build(VariableGroupOwlBuilder.java:140) at com.opensimulationplatform.core.owlbuilder.VariableGroupOwlBuilder.setVariableGroups(VariableGroupOwlBuilder.java:173) at com.opensimulationplatform.core.owlbuilder.VariableGroupOwlBuilder.build(VariableGroupOwlBuilder.java:141) at com.opensimulationplatform.core.owlbuilder.SimulatorOwlBuilder.lambda$setVariableGroups$5(SimulatorOwlBuilder.java:74) at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) at java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085) at com.opensimulationplatform.core.owlbuilder.SimulatorOwlBuilder.setVariableGroups(SimulatorOwlBuilder.java:68) at com.opensimulationplatform.core.owlbuilder.SimulatorOwlBuilder.build(SimulatorOwlBuilder.java:34) at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) at com.opensimulationplatform.core.owlbuilder.SystemStructureOwlBuilder.buildSimulators(SystemStructureOwlBuilder.java:49) at com.opensimulationplatform.core.owlbuilder.SystemStructureOwlBuilder.build(SystemStructureOwlBuilder.java:27) at com.opensimulationplatform.core.validation.ValidatorContextFactory.create(ValidatorContextFactory.java:26) at com.opensimulationplatform.core.validation.Validator.validate(Validator.java:75) at com.opensimulationplatform.cli.Validator.validate(Validator.java:66) at com.opensimulationplatform.cli.Main.main(Main.java:85)

Look into refactoring this to have each validation be a separate class which can also include an explanation for why that validation failed. Right now it is difficult to know exactly why the validation failed.

Create module osp-validator-cli and implement a simple command line interface towards osp-validator-core, osp-model-description and osp-system-structure

Some of the LOG.debug statements are better suited as LOG.trace

Currently, bonds are nondirectional, unlike plugs, sockets and variables. I hereby suggest that we make them directional. This would simplify all the code that deals with them, as it no longer has to be "smart" when it matches plugs and sockets in a bond connection. GUIs that show connections in a block diagram will automatically know which side of a block to put the connectors on.

The cost to users would be minimal; they just have to be a bit more explicit when defining their bonds.

Since bonds have mixed causality, the assignment of "direction" would of course be arbitrary, and the hard part is to find good names for the two directions. As a first suggestion, we could use "left" and "right" or "A" and "B".

From libcosim v0.8.0 proxified FMUs are now configured as:

<Simulator name="instance name" source="proxyfmu://localhost?file=model.fmu"/>

Add one example validating a OspSystemStructure.xml and one example validating a OspModelDescription.xml

This returns a ModelDescription object which is only populated by parsing modelDescription.xml in the fmu

The use of osp-validator
java -jar osp-cli.jar osp-system-structure -file OspModelDescription.xml
requires
xmlns="http://opensimulationplatform.com/MSMI/OSPSystemStructure" version="0.1"
in the xml attributes of OspSystemStructure tu finish succsessfully. But this file is not existent.
Using the correct address
"xmlns="https://opensimulationplatform.com/xsd/OspModelDescription" version="1.0.0"
ends up in an exeption.
This makes it impossible for external XML writers to generate a valid OspSystemStructure.xml or FMU_OspModelDescription.xml resp.
Please adjust also the documentation, as it already is done in
"https://opensimulationplatform.com/xsd/OspModelDescription-1.0.0-doc/OspModelDescription-1.0.0.html"

VariableGroupsType is missing an attribute "name".

OSP Validator cannot locate FMUs when the source is specified as an GUID, and using FMU proxy. For instance, <Simulator name="vessel_model" source="fmu-proxy://localhost:9090?guid=b71f76f7-b51e-40d5-affb-f63905622e2b" stepSize="0.05"/> resolves to _OspModelDescription.xml when locating the FMUs OSP-IS file.

I am wondering whether this should be supported by OSP-IS or not.

Fix .xsd

When defining the variable group AzimuthThrusterFeedback, BladePitchand ShaftSpeed are not treated as optional elements. The following definition leads to an exception in osp-cli

<AzimuthThrusterFeedback name="main_propeller_port_feedback"> <AzimuthAngle name="main_propeller_port_azimuth"> <Variable ref="thruster_states.main_propeller_port.azimuth"/> </AzimuthAngle> <Force name="main_propeller_port_thrust"> <Variable ref="thruster_states.main_propeller_port.thrust"/> </Force> </AzimuthThrusterFeedback>

with the following exception:

Exception in thread "main" java.lang.NullPointerException at com.opensimulationplatform.modeldescription.xml.converter.tentative.BladePitchTypeConverter.convert(BladePitchTypeConverter.java:26) at com.opensimulationplatform.modeldescription.xml.converter.tentative.AzimuthThrusterFeedbackTypeConverter.convert(AzimuthThrusterFeedbackTypeConverter.java:28) at com.opensimulationplatform.modeldescription.xml.converter.tentative.AzimuthThrusterFeedbackTypeConverter.convert(AzimuthThrusterFeedbackTypeConverter.java:18) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at com.opensimulationplatform.modeldescription.xml.converter.Converter.convert(Converter.java:26) at com.opensimulationplatform.modeldescription.xml.converter.generic.GenericTypeConverter.convert(GenericTypeConverter.java:273) at com.opensimulationplatform.modeldescription.xml.converter.generic.GenericTypeConverter.convert(GenericTypeConverter.java:66) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at com.opensimulationplatform.modeldescription.xml.converter.Converter.convert(Converter.java:26) at com.opensimulationplatform.modeldescription.xml.converter.ospmodeldescriptiontype.OspModelDescriptionTypeConverter.convert(OspModelDescriptionTypeConverter.java:110) at com.opensimulationplatform.modeldescription.xml.factory.ModelDescriptionFactory.create(ModelDescriptionFactory.java:22) at com.opensimulationplatform.cli.Validator.validate(Validator.java:60) at com.opensimulationplatform.cli.Main.main(Main.java:85)

OSP Validator does not recognise FMUs with fmu proxy is source. For instance, <Simulator name="vessel_model" source="fmu-proxy://localhost:9090?guid=b71f76f7-b51e-40d5-affb-f63905622e2b" stepSize="0.05"/> gives the following error message:

Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: Unsupported URI schema: 'fmu-proxy' in URI: 'fmu-proxy://localhost:9090?guid=b71f76f7-b51e-40d5-affb-f63905622e2b' . Supported schemas are: [file, fmuproxy] at com.opensimulationplatform.systemstructure.util.DefaultOspModelDescriptionLocator.get(DefaultOspModelDescriptionLocator.java:58) at com.opensimulationplatform.cli.Validator.getModelDescriptionErrorMessages(Validator.java:93) at com.opensimulationplatform.cli.Validator.validate(Validator.java:48) at com.opensimulationplatform.cli.Main.main(Main.java:79) Caused by: java.lang.RuntimeException: Unsupported URI schema: 'fmu-proxy' in URI: 'fmu-proxy://localhost:9090?guid=b71f76f7-b51e-40d5-affb-f63905622e2b' . Supported schemas are: [file, fmuproxy]

osp-validator will only work on JDK8 systems due to the dependency on JAXB. This might be hard to swallow for many.
However, JAXB can be used on newer JDKs if the dependency is explicitly listed.

    implementation group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.1'
    implementation group: 'org.glassfish.jaxb', name: 'jaxb-core', version: '2.3.0.1'
    implementation group: 'org.glassfish.jaxb', name: 'jaxb-runtime', version: '2.3.3'

Developers that want to autogenerate sources from xsd still need JDK8, but users may use any JVM version.

Validation fails if non-generic variable groups are listed before the generic variable groups in the <VariableGroups>. I don't remember if we already discussed this, but do we need to have this as a requirement?

In modelDescription.xml, BaseUnit in UnitDefinitions -> Unit is an optional element. Some modelling tools omit BaseUnit causing the validator to crash in Fmi2UnitConverter.java.

Setup:

• Configuration with two models (Damper and Mass, from tutorial example).
• Two outputs from the model Damper (df_0 and df_1) connected to the input from the model mass (in_f_u), as in the file attached (see next message).

Action 1:

• run the osp-validator on the configuration
  java -jar osp-cli.jar osp-system-structure -file "OspSystemStructure.xml"

Result 1:
No error!

Action 2:

• run the cosim-cli
  .\cosim.exe run "OspSystemStructure.xml"

Result 2:
Error message is shown:
error: Invalid system structure: Cannot establish connection between variables Damper1:df_1 and Mass1:in_f_u: Target variable is already connected to Damper1:df_0

I believe the osp-validator should be able to detect this type of error (multiple outputs connected to the same input), as this configuration would not run.