UniFMU v0.14.0

This release adds support for Array Variables for FMI3 based FMUs, clocks for blackbox FMI3 FMUs and precompilation of python based FMUs.
It also stabilizes the features added in the two previous pre-release versions v.0.12.0-beta and v.0.13.0-beta.
Full Changelog since last pre-release: v0.13.0-beta...v0.14.0
Full Changelog since last stable release: v0.11.1...v0.14.0

Precompilation of Python based FMUs

All python based FMUs now generate with scripts and resources for compiling the python code into binaries. The compilation is based on PyInstaller, which, if not present in the local environment, is fetched when the included compilation script is run.

Precompilation of the Python based FMUs is especially useful when the FMU has to be portable.

Array Variables

FMUs implementing FMI3 can now include Array Variables. This allows for setting and getting multidimensional variables without having to set a value reference for each scalar component. Instead, any non-scalar value can be get and set with one value reference as long as the values are structured correctly. Note that an Array Variable in this case is not just a vector, but any tensor of rank 1 or above.

Clocks for Blackbox FMUs

Blackbox FMI3 FMUs now also support clocked variables and associated functions.

UniFMU v0.13.0-beta

This release adds logging for all FMUs generated with UniFMU. It also fixes a memory leak, and changes how unexpected return values form the model are handled.
Full Changelog: v0.12.0-beta...v0.13.0-beta

Logging

It is now possible to enable debug logging for all FMUs generated with UniFMU. All models now include a logging function that, when called, will send log messages to the importer through the standard FMI logging callback API (specifics being FMI version dependent).

Log category filtering works out of the box, meaning that any importer will only get log messages for the log categories that they show interest in via calls to SetDebugLogging(). That being said, the models can also be extended with filtering by model implementers, which can greatly reduce the amount of messages sent between the model and the UniFMU API wrapper. This is especially useful if the FMU is distributed, such that the importer and UniFMU wrapper runs on a seperate machine form the model.

With this, all messages from UniFMUs previously send to stdout or stderr are now only send to the importer through the supplied logging callback. As a consequence, if distributed FMUs are used, ensure that the FMU importer has debug logging enabled and that at least the logUnifmuMessages log category is enabled. Otherwise the message, containing the endpoint that the remote part of the FMU should connect to, won't be emitted.

If logging and messages needs to be send to stdout or stderr, then that is still possible; build the UniFMU project (following the guide under "Building and Deployment" in the README) but add the feature flag fmt_logging when building the rust binaries.

Handling of unexpected values from the model

If the importer tries to get a value that per the FMI standard is disallowed because of the current state, the FMU will now get those values, but return a warning status. (Previously it would not get those values and return an error status.)

If the FMU is not able to return the values requested by a get function, it will now always early return with an appropriate status and error message. (Previously it would sometimes try to update the values with nonexistent or corrupt values.)

Bugfixes

• Fixed a memory leak in the fmi3GetBinary() implementation.

Pre-release status

This release has less test coverage than our normal releases. This is due to one of our test dependencies not currently supporting the full FMI3 API. The release will be in beta until we can remedy this. Expect more bugs, and do open an issue if any are encountered.

UniFMU v0.12.0-beta

Extended FMI3 support

This prerelease version extends UniFMUs coverage of the FMI3 API and adds further programming language support for FMI3 FMUs.
Full Changelog: v0.11.1...v0.12.0-beta

FMI3 coverage

UniFMU now includes the part of the FMI3 API necessary for Event mode and Clocks.

Programming language support

In addition to Python based FMI3 FMUs, it is now possible to generate files for C3 and Java based FMUs. Furthermore, the README for Python based FMUs has been updated with a note on using virtual environments.

Pre-release status

This release has less test coverage than our normal releases. This is due to one of our test dependencies not currently supporting the full FMI3 API. The release will be in beta until we can remedy this. Expect more bugs, and do open an issue if any are encountered.

UniFMU v0.11.1

Versioning update

This update does not come with new functionality, but the dependencies for the binaries have changed.

Full Changelog: 0.0.11...v0.11.1

New versioning scheme

The previous two releases were bug-fixes to release 0.0.9. They added no new functionality. This wasn't obvious from their versioning. To remedy this going forward, UniFMU now follows a basic semantic versioning with the caveat that until version 1.X.X any changes to MINOR version might come with changes to API. For example, the command structure of the UniFMU tool and the formatting of the generated files might change.

Any API changes will be disclosed in the new versions release notes.

All previous versions will be considered MINOR versions of MAJOR version 0. Thus, the previous release will be considered 0.11.0, and this release will be its first revision, 0.11.1.

Common versioning across subcrates

The versioning of the fmiapi subcrate will now follow the versioning of the primary unifmu crate. This is done to communicate compatibility between the crates, and to reflect the tight dependencie between the two crates and the overall UniFMU tool.

This will also be the case for any future subcrates.

Fixed versioning of Rust dependencies

Up until now the UniFMU tool has had wildcard version numbers for most of its dependencies, while the few with specified versioning had been specified down to their revision. This has been changed so that now all dependencies are set at an expected API stable versioning (MINOR number for all 0.X.X dependencies, MAJOR number for all 1.X.X or above, wtih a few exceptions).

This is done to ensure that UniFMU doesn't break due to a dependency update, while allowing dependency bug-fixes and security patches to automatically propagate into new releases.

0.0.11

Hotfix 2 for 0.0.9

Som unencountered bugs meant that Distributed Co-Simulation with black box FMUs wasn't working. These bugs have been squashed.

Full Changelog: 0.0.10...0.0.11

0.0.10

Hotfix for 0.0.9

• Backends will now be able to run their FreeInstance code without being rudely terminated by the rust code.
• The models of Java based FMUs are now serializeable enabling FMUstate functions. With this all FMI2 FMUs have functional FMUstate functions.
• Java FMUs are now actually tested by the test suite.

Full Changelog: 0.0.9...0.0.10

0.0.9

This release adds a new feature, increases the number of supported FMI functionality and increases codebase robustness.

New feature: Distributed Co-Simulation

With this release it is now possible to generate FMUs that act as a bridge to a simulation model hosted on a separate machine. These FMUs have the same interface as any other FMU, but only a thin communication layer is actually run locally when imported. This layer sends and receives messages to and from the core of the model which can be run from anywhere with an internet connection to the importer.
The core can be implemented in python, c# or java like other FMUs generated with UNIFMU, or it can be an already existing black box model for which the distributed FMU simply acts as a convenient communication layer.
This feature is currently implemented for FMI2 FMUs.

Expanded functionality: FMI2 State

fmi2GetFMUstate, fmi2SetFMUstate and fmi2FreeFMUstate along with the serialization functions have now been properly implemented for FMUs generated with UNIFMU. Using these functions it is now possible to explore multiple evolutions of an FMU without having to reevaluate the FMU from initialization.
EDIT 10/3-2025: Is not functional in Java. See issue #75

Increased robustness: New test suite and debug logging

A new testsuite has been build for the codebase using fmpy to evaluate the generated FMUs. fmpy is widely used by the community and has a solid implementation of the FMI specifications, which is why we trust it in the testing of our codebase. Using it we have been able to build better covering tests, and we expect that our new testsuite will help catch code errors earlier and more often than before.
Along with this we've added initial logging to the communication layer in the FMUs generated with UNIFMU which should help both us and users troubleshoot problems as they appear.

Full Changelog: 0.0.8...0.0.9

0.0.8

Updated minor things:

• fixed fmu zipping
• issues with build
• updated instructions for usage, build, and deployment

0.0.7

Add Java support

Implemented support for Java as a language for implementing FMUs.
The build system is based on Gradle

0.0.6

Removed automatic parsing of modelDescription.xml

Previously, the UniFMU binary would attempt to read and parse the modelDescription.xml file at runtime.
However, the specification does not guarantee that the file structure of a FMU is preserved or that the file is available in any capacity.
In these cases, the model's implementation would raise an exception.