setState__pTX error using different Media (Modelica.Fluid and Modelica.Media)

[uwe.schoeneich@…]

Using OM 1.9.1+dev (r18571)

If you are using not only one Medium but two or more within one Modelica.Fluid model, OM fails to simulate it. I created a simple example using two sources (not connected), default values for T,p,Xi and MoistAir + Water from Modelica.Media.

I works fine in Dymola but not in OM.
You could add and connect pipes and more boundaries, it will not work in OM.

Example:

model Testmodel_2Fluids
  Modelica.Fluid.Sources.Boundary_pT boundary(redeclare package Medium = Modelica.Media.Air.MoistAir) annotation(Placement(transformation(extent = {{-80,40},{-60,60}})));
  Modelica.Fluid.Sources.Boundary_pT boundary1(redeclare package Medium = Modelica.Media.Water.WaterIF97_ph) annotation(Placement(transformation(extent = {{-80,0},{-60,20}})));
end Testmodel_2Fluids;

Result:
Simulation failed

Result Output:
"C:\OpenModelica1.9.1Nightly
MinGW\bin\mingw32-make.exe" -j2 -f Testmodel_2Fluids.makefile
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids.o Testmodel_2Fluids.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_functions.o Testmodel_2Fluids_functions.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_records.o Testmodel_2Fluids_records.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_01exo.o Testmodel_2Fluids_01exo.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_02nls.o Testmodel_2Fluids_02nls.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_03lsy.o Testmodel_2Fluids_03lsy.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_04set.o Testmodel_2Fluids_04set.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_05evt.o Testmodel_2Fluids_05evt.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_06inz.o Testmodel_2Fluids_06inz.c
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/OpenModelica1.9.1Nightly//include/omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o Testmodel_2Fluids_07dly.o Testmodel_2Fluids_07dly.c
Testmodel_2Fluids_06inz.c: In function 'Testmodel_2Fluids_eqFunction_2':
Testmodel_2Fluids_06inz.c:87: error: too many arguments to function 'omc_Modelica_Fluid_Sources_BoundarypT_Medium_setStatepTX'
mingw32-make: * [Testmodel_2Fluids_06inz.o] Error 1
mingw32-make: * Waiting for unfinished jobs....
Compilation process exited with code 2

[Adrian Pop]

Hi,

This is a known bug and a fix is on the way.
Mostly because we generate a function with the same name
for the same type even if the component name is different.

Cheers,
Adrian Pop/

[Adrian Pop]

A workaround for now is this:

model Testmodel_2Fluids
  model M1 = Modelica.Fluid.Sources.Boundary_pT;
  model M2 = Modelica.Fluid.Sources.Boundary_pT;
  M1 boundary(redeclare package Medium = Modelica.Media.Air.MoistAir) annotation(Placement(transformation(extent = {{-80,40},{-60,60}})));
  M2 boundary1(redeclare package Medium = Modelica.Media.Water.WaterIF97_ph) annotation(Placement(transformation(extent = {{-80,0},{-60,20}})));
end Testmodel_2Fluids;

A fix for this is in the pipeline and hopefully I can commit it this week.

[anonymous]

Did this ever get fixed? I'm still being plagued by it.

[Adrian Pop]

Not yet. A solution is in the works but it took way more time than I expected.

[Martin Sjölund]

Fixed in r22496