MSL v3.2.2 (2016-04-03)

• Summary:
  • Version 3.2.2 is backward compatible to version 3.2.1, that is models developed with versions 3.0, 3.0.1, 3.1, 3.2, or 3.2.1 will work without any changes also with version 3.2.2 (with exception of the, usually uncritical, non-backwards compatible changes listed below with regards to external object libraries, and one bug fix introduced in 3.2.1 Build.3 for non-circular pipes that can be non-backwards compatible if a user constructed a new pipe model based on Modelica.Fluid.Pipes.BaseClasses.WallFriction.PartialWallFriction, see details below).
  • Short Overview:
    • This version of the Modelica package is compatible to Modelica Specification 3.2 revision 2
    • About 240 tickets have been fixed in this release and the previous maintenance releases:
      • Version 3.2.1 Build.3 (July 30, 2015) with respect to 3.2.1 Build.2 (August 14, 2013):
      • About 103 tickets have been fixed for this maintenance release.
      • Version 3.2.1 Build.4 (September 30, 2015) with respect to 3.2.1 Build.3 (July 30, 2015):
        • 10 tickets have been fixed for this release. In particular the following critical bug has been fixed:
          • Ticket #1768 fixes an
            issue with block CombiTimeTable(wrong output when using fixed time step integrator with time step
            greater than table resolution).
          • Ticket #1758 states that simulation of Modelica.Fluid.Examples.HeatingSystem fails in Dymola 2016 if option "pedantic mode for checking Modelica semantics" is set. This issue was not fixed in the library.
          • In ticket #1757 it is
            (correctly) stated that the example model PsychrometricData was moved to another location and that this is a non-backwards compatible change. This non-backwards compatible change is accepted, because it fixes a circular depedency (a model references a package in which it resides), for details see ticket #1679. Fixing this ticket is seen as of much higher priority, as the small drawback that an example model is moved (and the probability is very high that this moved model is not used in any user model).
      • Version 3.2.2 Build.2 (March 16, 2016) with respect to 3.2.1 Build.4 (September 30, 2015):
        • About 130 tickets have been fixed for this release.
        • The ModelicaStandardTables object library (.lib, .dll, .a, .so, depending on tool) has been split into the libraries ModelicaStandardTables, ModelicaMatIO, zlib and the new object library ModelicaIO has been added. For a tool vendor this can be a non-backwards compatible change if the same object libraries have been used in the past for different releases of package Modelica. In Resources/C-sources/_readme.txt the issue is explained in detail and how to resolve it. For a user this might be a non-backwards compatible change if he/she implemented an own external C interface function to one of the functions in the ModelicaStandardTables, ModelicaMatIO or zlib libraries. In this case, the library annotations to these functions need to be adapted.
    • In version 3.2.1+build.3 a new argument crossArea was introduced in the functions of Modelica.Fluid.Pipes.BaseClasses.WallFriction.PartialWallFriction to fix a subtle bug for the calculation of pipe friction for non-circular pipes, see #1601 and #1656. If a user utilized a pipe model of Modelica.Fluid.Pipes, this does not matter because the pipe models have been improved in a fully backwards compatible way. However, if the user constructed an own pipe model based on the partial package PartialWallFriction and calls the functions defined in PartialWallFriction with positional (and not named) arguments, then a unit warning or error will occur (depending on the tool and tool-specific settings) because the new argument crossArea has unit [m2] and the previous argument at this place, roughness, has unit [m]. If the warning is ignored, the simulation result will be wrong, because the crossArea is used as roughness. The user needs to fix this by adapting his/her pipe model so that the crossArea is used in the function calls, or by using named function arguments.
  • Detailed Release Notes