The mosaik team is delighted to announce the release of mosaik 3.5!

This version introduces two powerful new features: transform functions for connections and the ability to pause and resume simulations. In addition to this, we have also restructured the documentation and completely rewritten the tutorial.

The mosaik team is over the moon to announce the release of mosaik 3.4. This release brings some important bug fixes to the tiered-time system introduced in mosaik 3.3, and some new features that will hopefully help you in running your mosaik simulations more reliably.

First of all, we have made the internal async datastructures of mosaik available to you. This feature is intended for users who want or have to run mosaik in an existing asyncio event loop (for example, if you are running mosaik in a Jupyter notebook).

To profit from this, you can import AsyncWorld instead of World from the mosaik package. It is used similarly to World, except that many methods are now async and thus need to be called with await. This also means that you can run them asynchronously, for example, to start two simulators with long start-up times in parallel.

In addition to this, AsyncWorld is geared towards users who want to use mosaik as part of a larger project, and will not automatically print its greeting or logging. You can configure this by giving the skip_greetings and configure_logging keyword arguments when creating your AsyncWorld. These keyword arguments also exist for World, but the default values are different.

Second, both World and AsyncWorld are context managers now and can be used with a with or async with block, respectively. The advantage of this is that mosaik will keep the connection to the simulators open until the end of the block, instead of closing them in the run method. This way, you can still call extra methods on the simulators after the simulation, for example, to extract final results from the simulators.

Third, mosaik will automatically terminate processes that it started. This can be controlled by extending your SIM_CONFIG with the "auto_terminate" key, like so:

SIM_CONFIG: mosaik.SimConfig = {

“MySim” : {

“cmd”: “%(python)s mysim.py %(addr)s”,

“auto_terminate”: False,

},

}

Last, there are some bug fixes related to the new tiered-time system. If you ran into “cannot progress backwards” errors or into errors that some times are “incomparable”, these should be fixed now. Please let us know if you still run into issues like these.

Dear Co-Simulators,

The mosaik team is thrilled to announce that we have released mosaik 3.3 beta ! We want to give you the opportunity to test the new version at an early stage and give us feedback, so that we can improve the stable release.

⚠️ Be careful when testing the beta version, things may break! ⚠️

So, what’s new in mosaik 3.3?

The most notable change happens under the hood. We did an internal rework and refactoring of the time handling in mosaik. This shall increase the performance of mosaik noticeably - especially for scenarios with a huge amount of simulators - and also clarifies the implementation of the scheduling process. The scenarios that have worked with previous mosaik versions should work as before - nevertheless, we have already encountered an unexpected behaviour in certain scenarios which we are working on to fix. If you also encounter unexpected behaviour, let us know. This is what we have released the beta version for 🚀

We also have some other useful and more user-facing new features:

mosaik now provides a couple of basic simulators. These can be used to consume output, e.g., storing it in a dict or providing data, e.g., from a custom function.

A simulator can now be connected to itself if the connection is weak or time_shifted. This restriction is technically no longer necessary - now you have even more freedom creating your scenarios!

Last but not least, simulators can now return extra_info for created entities. This can, for example, be used for nominal voltages for nodes in a grid in a pandapower simulator.

Have fun with the new version! If you have feedback, write us a massage here on GitHub Discussions or if you find a bug, feel free to create an issue on GitLab.

We are proud to announce that you can now find us on GitHub 🥳. We are especially excited to welcome you to the Discussions feature where we want to get in contact with you 💬. You have a question, a feature request or want to generally discuss the amazing possibilities with co-simulation and mosaik? We are curious to hear from you! We still have our mailing list, but we see GitHub as the better place to exchange problems, solutions, and ideas. See you there!

The mosaik team is thrilled to introduce the latest release, mosaik 3.2. Now, let’s explore the new features.

One notable addition is the incorporation of a visualization tool to simplify understanding the debug information:

Among others, we included a dataflow graph, that shows the direction of the dataflow between simulators and if the connection is time-shifted/weak.

The execution graph shows the order in which the simulators are executed.

The execution time graph shows the execution time of the different simulators and you can also plot execution time per simulator.

We have an additional enhancement for Windows users: Starting now, you can open a new console window for simulators, providing a more comprehensive overview of the simulation process.

On another note, we made the decision to shift from SimPy to asyncio, primarily because of its more robust and active development. With this change, errors connected to a maximum packet size for messages between simulators should be fixed. We paid off a technical debt that we have carried for a long time.

In addition we released the mosaik-api-v3 in a seperate package. This will enable users to have simulators using different versions of the mosaik-api in the same virtual environment in the future. With this change we want to make it possible to continue the development of mosaik and its API without causing the users breaking changes with a new API release. The plan is that you can stay on your API version as long as the current mosaik version supports it and can develop new adapters with newer API versions or update your existing adapters one by one.

We also have some minor changes.

• We solved a bug related to incorrect triggering in certain cases.
• We lifted the restriction that only one weak connection per cicle is allowed. You can no w have as many weak connections as you want.

An overview of all changes, can be found in the issues in GitLab.

Have fun with the new version! If you see more potential to improve mosaik or find a bug, feel free to create an issue on GitLab.

You are interested in developing mosaik to be ready for the next challenges in co-simulation to come? Feel free to take a look at the open job positions at the OFFIS Energy division. Due to a new project especially for mosaik, we have open positions for core mosaik development.

The mosaik team is proud to announce the release of mosaik 3.1.

Mosaik now uses a loguru to log its output instead of simply writing it to stdout.

The output of the simulation progress is now handled by tqdm which provides a nice progress bar. By setting print_progress='individual' on your world.run call, you can get individual progress bars for your simulators.

We are also working towards more principled semantics for connecting simulators. To this effect, two features of mosaik have been deprecated:

• The concept of async_requests and set_data calls has been scheduled for removal in mosaik 4. We believe that simulations can be set up more cleanly by using time_shifted and weak connections. If you have a setup where asynchronous requests are needed, please get in touch via the mailing list or our GitLab issues.
• Direct connections between persistent outputs and trigger inputs and between non-persistent outputs and non-trigger inputs will no longer be supported in a future version of mosaik. Instead, we will provide adapters that encode the desired semantics more cleanly. If you’re currently using these types of connections, please get in touch via the mailing list or our GitLab issues so that we can learn about your requirements for these adapters.

Internally, mosaik now uses Python type annotations. These can improve your editor’s autocompletion and inline documentation. (See here if your type checker complains about the type of your SIM_CONFIG.)

Last but not least, the new release contains some bug fixes related to lazy stepping, negative max_advance values in same time loop, missing intial data in hybrid simulators, and None value in particular connection structure. An overview of all changes, can be found in the issues in GitLab.