We are pleased to announce the release of a third alpha version for mosaik2.

Changes in this version:

• [NEW] Hierarchical entities: Entities can now have a list of child entities (issue #14).
• [NEW] The World class now has a get_data() method that allows you to get data from entities while creating a scenario.
• [NEW] World.connect(a, b, ('X', 'X')) can now be simplified to World.connect(a, b, 'X').
• [NEW] Attribute Entity.full_id which uniquely identifies an entity: '<sid>/<eid>'
• [NEW] Attribute ModelFactory.meta which is the meta data dictionary of a simulator.
• [NEW] World() now accepts a configuration dictionary which can, e.g., specify the network address for mosaik.
• [NEW] Overview section for the docs
• [NEW] Description of the mosaik API in the docs
• [CHANGE] When you create entities, mosaik checks if the model parameters actually exists and raises an error if not (issue #9).
• [CHANGE] The mosaik API’s init() function now receives the simulator ID as first argument (issue #15).
• [CHANGE] The behavior of the get_related_entities() RPC that simulators can perform has been changed.
• [CHANGE] Various internal improvements
• [FIX] issue #18. Improved the error message if a Python simulator could not be imported.
• [REMOVED] Attribute Entity.rel.

This release introduced backwards incompatible changes, so you may have to update your simulators and scenarios.

The next release will (presumably) only add a few convenience functions and may be labeled as beta. If now big issues arise with that release, the release after that might be the final 2.0.

To get the new version, run pip install --pre -U mosaik from within your mosaik virtualenv.

We are pleased to announce the release of the second alpha for mosaik2.

Changes in the new version:

• [NEW] Preliminary documentation and installation instructions (https://mosaik.readthedocs.org)
• [NEW] Simulators can now set data to other simulators using the asynchronous request set_data (issue #1).
• [NEW] There is now a start timeout for external processes (issue #11).
• [CHANGE] Mosaik now raises an error if a simulator uses the wrong API version (issue #4).
• [CHANGE] Mosaik prints everything to stdout instead of using the Python logging module (issue #7).
• [FIX] issue #2. Scheduling now works properly for processes using async. requests. New keyword argument async_requests for World.connect().
• [FIX] issue #3. Local (in-process) Simulators can now also perform async. requests to mosaik (get_progress, get_related_entities, get_data, set_data).
• [FIX] issue #8. Cleaned up the code a bit.
• [FIX] issue #10. Tests for the sim manager improved.

There are still a few things that need to be done before we can release mosaik 2.0 (see open tickets). One of them will likely brake the current version of the mosaik API. :-)

To get the new version, run pip install --pre -U mosaik from within your mosaik virtualenv.

We compiled a list of questions we got during the last weeks and added them to mosaik’s documentaion. If your questions is not answered there, you’re welcome to post it to our mailing list.

It’s been one week since we inaugurated our SESA-lab and launched mosaik as an Open Source Framework for Smart Grid co-simulation. We received plenty of feedback from users telling us about their impression of mosaik (almost every single one describing a positive mosaik-experience). However, we received some mails regarding installation troubles, which led us to explain the installation process in more detail as well as adding support for a larger variety of operating systems.

We are currently compiling the questions, feedback and support from our side into an FAQ-section, which should be available soon. So make sure to subscribe to the mosaik mailing-list or subscribe to our news feed.

Today, we inaugurate our Smart Energy Simulation and Automation (SESA) lab at the OFFIS Institute, which nicely integrates into the mosaik environment. The focus of the SESA lab is to integrate real-time models (MATLAB Simulink-based) running on dedicated target machines into a mosaik-orchestrated large-scale Smart Grid environment. Of course, this raises a lot of technical as well as conceptual questions we need to address.

We currently develop models for the real-time environment that are easily comprehensible on the one hand and allow parameter access during runtime on the other hand. Another task is to properly deal with one or more real-time components within the mosaik environment. This imposes a global clock into the otherwise event-based (and thus indirectly timed) simulation. Keeping this timing constraint in a large hybrid environment is surely a challenge. One could tackle it by balancing the distributed mosaik simulation onto multiple machines and thus allow for synchronization at precise intervals.

We will keep you updated about progress here and hope that this feature will interest many prospective users of mosaik.

Since nearly four years, we’ve been developing and working with mosaik within our research group at OFFIS. Now, we finally have the opportunity to release it as Open Source Software.

Before mosaik was developed, we manually combined results of different simulators with Excel to gain some knowledge about the interaction of active components of smart grids.

We soon realized, that this was not the way to go and started the project “mosaik – modulare Simulation aktiver Komponenten im Verteilnetz” (which roughly translates to “modular simulation of active components in the distribution grid”).

Our first prototype hard coded some simulators (for photovoltaic, electric vehicles and load flow analysis) in an event loop. This beast already allowed us to perform some interesting simulations within the Grid Surfer project.

My former colleague Steffen Schütte then began his PhD-thesis about coupling existing simulators and creating large-scale Smart Grid scenarios. During that period, we created mosaik 1. With this, we really made a big step forward and were able to simulate scenarios with several simulator types, more than hundred simulator instances and more than seventy thousand simulated entities.

Mosaik 1, as a project that was created during a PhD-thesis, had its problems, though. It was hard to maintain because it used too many different technologies from both, the Python and the Java world. It had some features that seemed useful by that time but turned out to be not that important. On the other hand, extending the scenario description language (mosl), which was an Xtext based DSL, proved to be too hard and inflexible.

So with everything we learned during the development of mosaik 1, we started from scratch at the end of last year and created mosaik 2. It still lacks some of the features of mosaik 1, but is already usable in a much more comfortable manner than mosaik ever was.

We hope that by making it Open Source, we can reach a broader audience and more Users and build up a vibrant community. With mosaik 2 we hope to initiate collaborative projects with other institutes and experts from different disciplines to simulate the effects of various control strategies within extensive energy systems of tomorrow.