FMI3 Types definitions by davidhjp01 · Pull Request #808 · open-simulation-platform/libcosim

davidhjp01 · 2026-09-21T06:23:43Z

Depends on PR #807

Summary

Extends the shared model-description layer with FMI 3 value types, arrays,
metadata, and detailed step outcomes while preserving existing FMI 1/2
behavior.

Changes

Add FMI 3 types: Float32, signed and unsigned integer widths, Binary, and
Clock.
Add FMI 3 causality values, typed value references, Enumeration and Binary
values, and type-safe scalar/array storage.
Add variable_value with:
- exact type and size access;
- scalar and flat row-major array values;
- dimension validation;
- overflow-safe flat_size() calculation.
Extend variable and model metadata with:
- FMI 3 instantiation tokens;
- declared types, units, display units, bounds, and nominal values;
- aliases, derivatives, previous variables, clocks, and array dimensions;
- Enumeration, Binary, and Clock definitions.
Add fixed_shape() to distinguish fixed arrays from arrays sized by
structural parameters.
Add step_result_info/step_outcome for actual completion time, early
return, event handling, termination requests, and retryability.
Make existing execution paths exhaustive:
- unsupported initial-value types now fail explicitly;
- generic value validation recognizes the new typed values.

Compatibility and scope

Existing FMI 1/2 scalar types and execution behavior remain supported.
New metadata and value types provide the common foundation for FMI 3
importer and typed-access work.
This branch does not by itself add FMI 3 FMU loading or runtime get/set
operations.

Use FMI Library 3.0.4 and carry the repository CI/package updates needed by the FMI 3 stack.

Implement validated FMI 2 directional derivatives with a dedicated fixture, reference-FMU wiring, and contract tests.

Use FMI Library 3.0.4 and carry the repository CI/package updates needed by the FMI 3 stack.

Implement validated FMI 2 directional derivatives with a dedicated fixture, reference-FMU wiring, and contract tests.

Introduce the common exact type metadata, dimensions, declared-type structures, and owning variable-value model used by later FMI 3 layers.

Reject unsupported initial value types explicitly and recognize newly declared scalar types during metadata validation so the common value model remains buildable before later integration layers.

kyllingstad · 2026-09-22T08:46:03Z

I'll review this one once #807 is done, in case there are changes which propagate to this PR.

…paration

…metadata # Conflicts: # .github/workflows/ci-cmake.yml # include/cosim/fmi/v2/fmu.hpp # src/cosim/fmi/v2/fmu.cpp # tests/CMakeLists.txt # tests/fmi_v2_fmu_unittest.cpp

# Conflicts: # tests/CMakeLists.txt

restenb

Left some comments, but as far as I can see this covers the base FMI3 spec very well.

restenb · 2026-09-22T14:01:29Z

+    std::vector<value_reference> outputReferences_;
+    std::vector<value_reference> derivativeReferences_;
+    std::vector<value_reference> initialUnknownReferences_;
+    std::vector<value_reference> continuousStateReferences_;


One thing that immediately confused me is that there is no /fmi/v3 with the actual implementation of a v3::fmu. If the intention was to just add the new type vocabulary in this PR that's still fine. But right now this PR is a large new API surface that immediately panics if anybody tries to use it.

Yes, files in fmi/v3 will be added in the next PR.

restenb · 2026-09-22T14:27:24Z

@@ -30,39 +33,81 @@ using value_reference = std::uint32_t;
 /// Variable data types.
 enum class variable_type


We can at least see that we are going from ~5 to ~15 types in this enum. This is used all over the code base in switch statements like this one from fixed_step_algorithm.cpp:

The switch only exists to pick the correct method to call e.g. target->set_real(ref, source->get_real(ref)). Maybe we can hide these details behind a type agnostic function or interface so we can instead just write something like target->set(c.target, source->get(c.source)) and do away with all the duplicate switch cases by hiding it inside that boundary. But we still want to know the type outside that interface, so the mechanism has to be thought through a bit.

I think this will be addressed in the later PR

restenb · 2026-09-25T12:57:20Z

+enum class clock_interval_variability
+{
+    /// No scheduling information is available.
+    unknown,


According to the Clock specs, unknown is not a valid type?
https://fmi-standard.org/docs/3.0/#Clock

It is to keep consistent with what fmi-library implemented: https://github.com/modelon-community/fmi-library/blob/1599ab1e61eeb224db307a0d8893ee284168beff/src/Util/include/FMI3/fmi3_enums.h#L170

restenb · 2026-09-25T13:32:48Z

+struct variable_dimension
+{
+    /// FMI value reference of the structural parameter.
+    value_reference structural_parameter = 0;


Per the spec https://fmi-standard.org/docs/3.0/#ModelVariables, it sounds like this can point either at a structural parameter or a constant UInt64. In either case the reference value is just used to determine the size, so a name like size_reference might be more appropriate?

And a follow-up to the above, do we also need to model the constant option here, or is that OK to omit?

I think nearby in the code there was a fixed_variable_dimension or similar type?

In schema, it is defined as valueReference (e.g. <Dimension valueReference="...">), so I think it would be good to preserve the naming.

And a follow-up to the above, do we also need to model the constant option here, or is that OK to omit?

I think nearby in the code there was a fixed_variable_dimension or similar type?

fixed_dimension is used for that purpose

restenb · 2026-09-25T13:50:17Z

+        variable_type::uint32,
+        variable_type::int64,
+        variable_type::uint64,
+        variable_type::enumeration,


Elsewhere we have enumeration after string, for example in the variable_value_storage variant. Maybe we should stick to one ordering everywhere where the variable_types are in use.

restenb · 2026-09-25T14:17:35Z

 /// Variable data types.
 enum class variable_type
 {
+    /// FMI Float64.


A point to consider is whether we keep the legacy FMI2 names with us or not. Since FMI3 replaced e.g. real with float64, do we want to reflect that. Would require us to split variable_type implementations between FMI2 and FMI3 though.

We can still have single variable_type, but define both that can be interchangeable.

… for type equivalence

davidhjp01 added 10 commits September 18, 2026 16:03

Upgrade FMI Library and CI integration

05780cf

Use FMI Library 3.0.4 and carry the repository CI/package updates needed by the FMI 3 stack.

Add FMI 2 directional derivative support

4900550

Implement validated FMI 2 directional derivatives with a dedicated fixture, reference-FMU wiring, and contract tests.

Updated conanfile.py

730e739

Updated back the conan cicd

2a23bff

Added "Shlwapi" dependency for Windows build

a393c6d

Upgrade FMI Library and CI integration

af261b7

Use FMI Library 3.0.4 and carry the repository CI/package updates needed by the FMI 3 stack.

Add FMI 2 directional derivative support

ce90f6a

Implement validated FMI 2 directional derivatives with a dedicated fixture, reference-FMU wiring, and contract tests.

Add FMI 3 common type and value metadata

a4f1b6b

Introduce the common exact type metadata, dimensions, declared-type structures, and owning variable-value model used by later FMI 3 layers.

Keep existing execution visitors exhaustive

7605b83

Reject unsupported initial value types explicitly and recognize newly declared scalar types during metadata validation so the common value model remains buildable before later integration layers.

Updated

43fc698

davidhjp01 requested review from eidekrist, kyllingstad and restenb September 21, 2026 06:23

davidhjp01 added 3 commits September 21, 2026 08:24

Refactor CI configuration and update Conan package upload steps

a45b634

Added "Shlwapi" dependency for Windows build

bc8e506

Add FMI 3 common types and metadata, enhancing model-description layer

d5811d2

davidhjp01 self-assigned this Sep 21, 2026

davidhjp01 added the fmi3 label Sep 21, 2026

davidhjp01 added 7 commits September 22, 2026 13:21

Merge branch 'master' into fmi2-directional-derivatives

1102000

Refactor lifecycle state management and error handling in FMU simulation

d4d4313

Enhance test executable configuration and add Dahlquist test data pre…

6043a67

…paration

Updated

fc1ec8d

Merge branch 'fmi2-directional-derivatives' into libcosim/fmi3-types-…

fc23820

…metadata # Conflicts: # .github/workflows/ci-cmake.yml # include/cosim/fmi/v2/fmu.hpp # src/cosim/fmi/v2/fmu.cpp # tests/CMakeLists.txt # tests/fmi_v2_fmu_unittest.cpp

Updated

adeb080

Merge branch 'master' into libcosim/fmi3-types-metadata

ddf856f

# Conflicts: # tests/CMakeLists.txt

davidhjp01 requested a review from joakimono September 25, 2026 12:50

restenb reviewed Sep 25, 2026

View reviewed changes

davidhjp01 added 2 commits September 28, 2026 13:13

Add enumeration_value type handling in variable_type determination

2a4bf0d

Enhance variable_type enumeration with FMI 3 names and add unit tests…

525df68

… for type equivalence

davidhjp01 requested a review from restenb September 29, 2026 07:11

		@@ -30,39 +33,81 @@ using value_reference = std::uint32_t;
		/// Variable data types.
		enum class variable_type

Conversation

davidhjp01 commented Sep 21, 2026

Depends on PR #807

Summary

Changes

Compatibility and scope

Uh oh!

kyllingstad commented Sep 22, 2026

Uh oh!

restenb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

restenb Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidhjp01 Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

restenb Sep 28, 2026 •

edited

Loading

davidhjp01 Sep 28, 2026 •

edited

Loading