Dear all,

There is a meeting of the FMI (www.functional-mockup-interface.org) design group Monday and Tuesday next week where most likely the level of ambition of FMI 2.0 will be settled. Different application areas have different needs and priorities and I think it would be wise to provide some input from the building simulation community to this meeting. Let me first give some background.

The ultimate purpose of equation based simulation and Modelica (www.modelica.org) is to enable model exchange between users and tools. However, the Modelica language is by necessity a very complex and rapidly evolving "beast." It is essentially impossible to keep tools in good sync with each other in their interpretation of Modelica. In practice, this means that porting complex model libraries, such as the MSL Fluid and Media libraries and derivatives, from one tool to another often involves man years of work, if possible at all. This is where FMI comes in. FMI provides a means to exchange pre-compiled model units and this can be radically simpler than to achieve a common understanding and interpretation of the underlying Modelica code. FMI 1.0 has proven this since a number of years. However, for our application FMI 1.0 is severely limited.

There are three key areas where FMI 2.0 has previously been planned to be enhanced in ways that in my opinion are essential to the building simulation community:

- Introduction of physical connectors (now only direct variable-to-variable connections are supported)

- Support for arrays, the size of which is determined by parameters that can be changed after compilation (only scalars in FMI 1.0)

- Support for sparse analytical Jacobians

In the building simulation world of multiple-port tanks and zones, where many components are built around discretized PDE:s, FMI without these features is unlikely to become very useful. At the same time the FMI design group is facing some seriously conflicting goals:

- FMI must not be too rapidly evolving - otherwise much of the purpose is lost

- The standard must not be too complex for vendors to support

- There is an urgent need to upgrade v. 1.0 to something more powerful

Therefore, there is a distinct risk that some of the planned enhancements of 2.0 are postponed. For reasons of stability, it could take a very long time before the next major release.

If you share my concern about these issues, please write a few lines to underline why we need these features to me. I will compile for the FMI design committee.

Best regards,

Per Sahlin