@robha67 It is well known problem Currently OMSimulator does not import ssp from other tools due to internal oms_solver information needed in <oms:Annotations> , given below.

<ssd:Annotations>
    <ssc:Annotation type="org.openmodelica">
        <oms:Annotations>
            <oms:SimulationInformation>
                <oms:FixedStepMaster description="oms-ma" stepSize="0.001000" absoluteTolerance="0.000100" relativeTolerance="0.000100" />
            </oms:SimulationInformation>
        </oms:Annotations>
    </ssc:Annotation>
</ssd:Annotations>

We are currently working on this issue, to import SSP from all tool vendors, But the reverse should be possible export an ssp from OMSimulator and it should be imported in other tools, we checked our exported ssp with easySSP and it got successfully validated.

@arun3688 Does the information above concern ME FMUs in the SSP or both CS and ME? If also for CS, could you explain why this information is needed?

@robha67 It is for both ME and CS, Currently OMSimulator supports the following solver

• oms-ma - FixedStepMaster - Weakly Connected
• oms-mav – VariableStepMaster - Strongly Connected
• oms-mav2- VariableStepMaster - Strongly Connected

The solver determines whether the system belongs to StronglyConnected(ME) or WeaklyConnected(CS), In SSP 1.0 specification there is no way to tell whether the system belongs to SC or WC, But if you can put the above ssd:annotation to the external ssp specifying what type of System then it will work in OMSimulator

1. Ok, but if you import an SSP where this information is missing, could OMS set default values with some potential warnings?

2. But I guess that you can add a solver through the API after importing an SSP that lacks this information? If so, then this should not be an issue for Viktors specifik case provided that this is what causes his problem; he could simply add a solver after importing his SSP.

@arun3688

• Ok, but if you import an SSP where this information is missing, could OMS set default values with some potential warnings?

Yes we can do that me and lennart had this discussion regarding this, But we could not find a proper way to fix the solution, may be the default should be always set to Strongly connected (ModelExchange) and if the fmu's don't support ModelExchange we can warn the users

2. But I guess that you can add a solver through the API after importing an SSP that lacks this information? If so, then this should not be an issue for Viktors specifik case provided that this is what causes his problem; he could simply add a solver after importing his SSP.

Yes this is still possible right now, but without an API, Viktor can simply add the above ssd:Annotations to the .ssd file and the simulation will work. As you said it should also be possible to add the solver via an API, I will implement this and i will have some discussion with @lochel, Can you please comment on this

May require significant modifications to OMSimulator core.
From an end-user perspective, we need to be able to import an SSP and schange the settings (for example regarding WC or SC) after import. Some default values can be exploited upon initial import, for example all CS FMUS are put into individual WC components and all ME FMUs are put into individual SC components.

Note that any meta-data that cannot put directly in the SSP, we put in the formats of the LS-SSP Traceability.

We’ve decided to address these compatibility and usability challenges by initiating development on OMSimulator 3, which will involve some significant architectural changes and breaking API compatibility with previous versions. Key updates include:

1. Unified System Structure: OMSimulator 3 will drop support for Weakly Connected (WC), Strongly Connected (SC), and TLM systems. Instead, we’ll have a single, unified “System” structure. Partitioning will be determined based on solver information provided for each FMU, simplifying configuration and enhancing flexibility.

2. Introducing support for FMI 3: We plan to replace TLM support with native FMI 3.0 integration, which will provide robust co-simulation features and replace the need for TLM by leveraging the capabilities in FMI 3.0.

3. New API Design: This refactor will result in a cleaner, more intuitive API that aligns with current FMI and SSP standards. While this change will break backward compatibility, we’ll offer guidance to help users migrate from OMSimulator 2 to OMSimulator 3. Additionally, we plan to provide an automatic conversion for SSP files created in OMSimulator 2 to ensure compatibility with existing models.