Opened 5 years ago

Closed 5 years ago

#5904 closed defect (fixed)

Several issues

Reported by: anonymous Owned by: somebody
Priority: high Milestone: 1.14.1
Component: *unknown* Version:
Keywords: Cc:

Description

This bug file refers to 3 misbehaviours or bugs of OpenModelica.

1) I receive the error "Function Utilities.regRoot2 not found in scope Valve" while Dymola manages the code correctly.

The problem ha been illustrated at length [here](​https://stackoverflow.com/questions/60900784/broken-modelica-fluid-valves-valveincompressible-model-receiving-error-functio?noredirect=1#comment107840854_60900784) and [here](​https://github.com/modelica/ModelicaStandardLibrary/pull/3528#event-3184374019)

To reproduce try to run the TestIdealPressureGenerator.mo file.

2) OpenModelica fails to run a model complaining "Symbolic Error
The initialization problem of given system is mixed-determined. It is under- as well as overdetermined and the mixed-determination-index is too high. [index > 10]
Please checkout the option "--maxMixedDeterminedIndex" to simulate with a higher threshold or consider changing some initial equations, fixed variables and start values.". Dymola successfully executes.

The point is that OM fails to understand that despite the initial condition is set twice, it is coherent. Alternatively, the software should make it very clear which is the offending equation. What about making mandatory to initialise via modifying clause?

To reproduce try to run TestIdealHeatExchanger.mo .

3) OpenModelica fails to warn about incoherent unit of measure while Dymola does. Taking advantage of dimensional analysis would be better.

To reproduce try to run TestIdealHeatExchanger.mo .

Attachments (1)

SHCLibrary.zip.gpg​ (21.8 KB ) - added by anonymous 5 years ago.
Confidential Test Library (to be used only for addressing the issues in the request)

Download all attachments as: .zip

Change History (20)

by anonymous, 5 years ago

Attachment: SHCLibrary.zip.gpg​ added

Confidential Test Library (to be used only for addressing the issues in the request)

comment:1 by Karim Adbdelhak, 5 years ago

The attachment is gpg encrypted, i cannot open it.

comment:2 by Karim Adbdelhak, 5 years ago

Nevermind, i just was given access to the official OSMC gpg key. I did not know that such a thing exists!

comment:3 by Per Östlund, 5 years ago

Does the first issue still happen in master? It might be that it's the same issue as in #5900, that I fixed two days ago.

comment:4 by Per Östlund, 5 years ago

I checked the first issue myself, and it was indeed the same as in #5900. So by happy coincidence it got fixed in between you posting about it on SO and reporting it here. The fix should already be in the latest nightly build if you want to try it out yourself.

comment:5 by anonymous, 5 years ago

Dear all,

I see that 1) was indeed a bug. I am happy to hear that I was already resolved.

Regarding point 3) IdealHeatExchanger.MXi[Medium.nXi] is declared (incorrectly) as SI.Energy but it is used (correctly) as SI.Mass. This notwithstanding, I receive no warning about incorrect dimensions from OM.

Hope this is useful, thank you very much for the very good job providing the OM tools for the community.

P.S. Doe the OM forum account work in this tracking system or do you need a different one?

comment:6 by anonymous, 5 years ago

Regarding point 2, I though I understood it, but in fact I did not. I can't explain why this code works.

model TestUnusedVariableWithInit

  Modelica.SIunits.Velocity v(start = 10);

initial equation

  v = 20;
  
equation

  der(v) = 0;
  
end TestUnusedVariableWithInit;

in reply to:  6 comment:7 by Karim Adbdelhak, 5 years ago

Replying to anonymous:

Regarding point 2, I though I understood it, but in fact I did not. I can't explain why this code works.

model TestUnusedVariableWithInit

  Modelica.SIunits.Velocity v(start = 10);

initial equation

  v = 20;
  
equation

  der(v) = 0;
  
end TestUnusedVariableWithInit;

Why shouldn't it work? You declare a state v which has to be provided initial information. Since you did not set fixed=true to the state, the start value will not be used for initialization because you provided enough other initial equations for the system to be balanced.

v gets initialized with 20 and during the simulation the derivative is fixed to zero, so it stays at 20.

What did you expect happening? If you set fixed=true for vit crashes, the error message is misleading i guess we should update that, but it is due to a overdetermined initial system which cannot be resolved (20 <> 10).

Last edited 5 years ago by Karim Adbdelhak (previous) (diff)

in reply to:  5 ; comment:8 by Francesco Casella, 5 years ago

Replying to anonymous:

P.S. Does the OM forum account work in this tracking system or do you need a different one?

I'm not sure, @adrpo can you please comment on that?

comment:9 by Francesco Casella, 5 years ago

Regarding issue 3), it should have been fixed already, see #5685.

Please try with the latest nightly build and report.

in reply to:  8 comment:10 by Adrian Pop, 5 years ago

Replying to casella:

Replying to anonymous:

P.S. Does the OM forum account work in this tracking system or do you need a different one?

I'm not sure, @adrpo can you please comment on that?

No. They are separate systems, in the Trac I am creating users manually.

comment:11 by Francesco Casella, 5 years ago

@anonymous, please write to adrian.pop@… to ask for an account.

comment:12 by anonymous, 5 years ago

Dear Adrian,

I tested it with v1.16.0-dev-262-g58c7a5314 (64-bit) and I confirm that issue 1) and 3) are solved.

However, I noticed that the warning about the incorrectness of the units does not appear if the object declared is a vector with size zero (in my example the mass fractions SI.Energy MXi[Medium.nXi] with nXi = 0). This I think depends on the order of the operations "check units" and "get rid of useless equations/variables". I have no idea of how difficult is to do, but ideally, the more problems (and the sooner) the compiler can spot, the better.

Regarding point 2 I think my code embeds a conceptual failure. I let you know my findings.

Thank you very much for the help and all the best.

in reply to:  12 comment:13 by Per Östlund, 5 years ago

Replying to anonymous:

This I think depends on the order of the operations "check units" and "get rid of useless equations/variables".

In the new frontend the unit checking is done between flattening and model simplification, and equations with zero size are removed during simplification. So the size of the equation shouldn't affect what's passed to the unit checking. I tried it with a trivial test model:

model M
  Real x[0];
equation
  x = ones(0);
end M;

and the equation is indeed passed to the unit checking. So I don't think it's a matter of in what order things are done, but rather how the unit checking handles such equations. But I don't really know how the unit checking works, so I can't say exactly what the issue is.

comment:14 by anonymous, 5 years ago

Well, a smaller code to reproduce point 3) is this:

model TestDimAnalysis
 
  import SI = Modelica.SIunits;
//  import Medium = Modelica.Media.Water.ConstantPropertyLiquidWater; 
  import Medium = Modelica.Media.Air.MoistAir; 

  parameter SI.Mass M = 1;
  
  Medium.BaseProperties medium;
  SI.Energy nrg[Medium.nXi]; // Wrong unit on purpose. It should be mass
  
equation

  nrg = M*medium.Xi;
end TestDimAnalysis;

I don't see any warning with v1.16.0-dev-262-g58c7a5314 (64-bit)

in reply to:  14 ; comment:15 by Karim Adbdelhak, 5 years ago

Replying to anonymous:

Well, a smaller code to reproduce point 3) is this:

model TestDimAnalysis
 
  import SI = Modelica.SIunits;
//  import Medium = Modelica.Media.Water.ConstantPropertyLiquidWater; 
  import Medium = Modelica.Media.Air.MoistAir; 

  parameter SI.Mass M = 1;
  
  Medium.BaseProperties medium;
  SI.Energy nrg[Medium.nXi]; // Wrong unit on purpose. It should be mass
  
equation

  nrg = M*medium.Xi;
end TestDimAnalysis;

I don't see any warning with v1.16.0-dev-262-g58c7a5314 (64-bit)

I am using OpenModelica 1.16.0~dev-260-g390e593 on Ubuntu and this model throws following errors:

"Error: Too few equations, under-determined system. The model has 22 equation(s) and 25 variable(s).
[/usr/lib/omlibrary/Modelica 3.2.2/Media/Air/MoistAir.mo:61:5-61:72:readonly] Warning: Variable medium.p_steam_sat does not have any remaining equation to be solved in.
  The original equations were:
  Equation 17: medium.phi = medium.p * medium.Xi[1] / ((medium.Xi[1] + 0.6219647130774989 * medium.X_air) * medium.p_steam_sat), which needs to solve for medium.phi
  Equation 15: medium.x_sat = 0.6219647130774989 * medium.p_steam_sat / max(1e-13, medium.p - medium.p_steam_sat), which needs to solve for medium.x_sat
  Equation 3: medium.X_sat = min(medium.p_steam_sat * 0.6219647130774989 / max(1e-13, medium.p - medium.p_steam_sat) * (1.0 - medium.Xi[1]), 1.0), which needs to solve for medium.p
  Equation 2: medium.p_steam_sat = min(Modelica.Media.Air.MoistAir.saturationPressure(medium.T), 0.999 * medium.p), which needs to solve for medium.T
[/usr/lib/omlibrary/Modelica 3.2.2/Media/Air/MoistAir.mo:54:5-54:67:readonly] Warning: Variable medium.X_liquid does not have any remaining equation to be solved in.
  The original equations were:
  Equation 8: medium.R = 287.0512249529787 * medium.X_air / (1.0 - medium.X_liquid) + 461.5233290850878 * medium.X_steam / (1.0 - medium.X_liquid), which needs to solve for medium.R
  Equation 5: medium.X_steam = medium.Xi[1] - medium.X_liquid, which needs to solve for medium.X_steam
  Equation 4: medium.X_liquid = max(medium.Xi[1] - medium.X_sat, 0.0), which needs to solve for medium.X_sat
[/usr/lib/omlibrary/Modelica 3.2.2/Media/package.mo:4478:7-4479:50:readonly] Warning: Variable medium.Xi[1] does not have any remaining equation to be solved in.
  The original equations were:
  Equation 20: nrg[1] = M * medium.Xi[1], which needs to solve for nrg[1]
  Equation 19: medium.X[2] = 1.0 - medium.Xi[1], which needs to solve for medium.X[2]
  Equation 18: medium.Xi[1] = medium.X[1], which needs to solve for medium.X[1]
  Equation 17: medium.phi = medium.p * medium.Xi[1] / ((medium.Xi[1] + 0.6219647130774989 * medium.X_air) * medium.p_steam_sat), which needs to solve for medium.phi
  Equation 16: medium.x_water = medium.Xi[1] / max(medium.X_air, 1e-13), which needs to solve for medium.x_water
  Equation 7: medium.h = Modelica.Media.Air.MoistAir.specificEnthalpy_pTX(medium.p, medium.T, medium.Xi), which needs to solve for medium.h
  Equation 6: medium.X_air = 1.0 - medium.Xi[1], which needs to solve for medium.X_air
  Equation 5: medium.X_steam = medium.Xi[1] - medium.X_liquid, which needs to solve for medium.X_steam
  Equation 4: medium.X_liquid = max(medium.Xi[1] - medium.X_sat, 0.0), which needs to solve for medium.X_sat
  Equation 3: medium.X_sat = min(medium.p_steam_sat * 0.6219647130774989 / max(1e-13, medium.p - medium.p_steam_sat) * (1.0 - medium.Xi[1]), 1.0), which needs to solve for medium.p
  Equation 1: medium.MM = 1.0 / (34.52428788658843 + 20.98414717520355 * medium.Xi[1]), which needs to solve for medium.MM
"

I have not looked too deep into your model but this error seems about right.

NOTE: Unit checking is not activated by default. You can activate frontend unit checking with -d=frontEndUnitCheck if you use the new frontend or -d=oldFrontEndUnitCheck if you use the old one. There also is a backend module for unit checking which you can activate with --preOptModules+=unitChecking. The module at hand seems to break before any of those modules can be applied.

You can test the flags with this simple Module:

model TestDimAnalysis
 import SI = Modelica.SIunits;
 SI.Mass M;
 SI.Energy E; // Wrong unit on purpose. It should be mass
equation
  E = sin(time);
  M = E;
end TestDimAnalysis;

With the new frontend unit check i get:

[1] 22:05:20 Translation Warning
[TestDimAnalysis: 11:3-11:8]: The following equation is INCONSISTENT due to specified unit information: M = E

[2] 22:05:20 Translation Warning
The units of following sub-expressions need to be equal:
- sub-expression "E" has unit "J"
- sub-expression "M" has unit "kg"

With the backend unit checking i get:

[1] 22:06:59 Translation Warning
The following equation is INCONSISTENT due to specified unit information: M = E
The units of following sub-expressions need to be equal:
- sub-expression "E" has unit "J"
- sub-expression "M" has unit "kg"

I am not quite sure why one should prefer one over the other but the frontend is newer so i would recommend using that.

in reply to:  15 comment:16 by Anton.Soppelsa@eurac.edu, 5 years ago

Sorry Karim,

I wasn't clear. My example cannot be executed because it is unbalanced. However, that should not matter because I expected (and in fact it is like that) that unit checking is done before.

Apprently, on Windows, the unit checking flag are enable by default. This is the result of pressing the button "Check model" and then "Flatten model" on my example first and then on yours.

[1] 16:08:15 Scripting Notification
Check of TestDimAnalysis completed successfully.

[1] 16:08:18 Scripting Notification
Instantiation of TestDimAnalysis completed successfully.

[1] 16:08:25 Translation Warning
[new: 7:3-7:8]: The following equation is INCONSISTENT due to specified unit information: M = E


[2] 16:08:25 Translation Warning
The units of following sub-expressions need to be equal:
- sub-expression "E" has unit "J"
- sub-expression "M" has unit "kg"

[3] 16:08:25 Scripting Notification
Check of TestDimAnalysis2 completed successfully.

[1] 16:08:29 Scripting Notification
Instantiation of TestDimAnalysis2 completed successfully.

As you can see, in my model the warning is not generated, in your it is.

This is my point: warning should be generated when checking my original test model as well.

Replying to Karim.Abdelhak:

Replying to anonymous:

Well, a smaller code to reproduce point 3) is this:

model TestDimAnalysis
 
  import SI = Modelica.SIunits;
//  import Medium = Modelica.Media.Water.ConstantPropertyLiquidWater; 
  import Medium = Modelica.Media.Air.MoistAir; 

  parameter SI.Mass M = 1;
  
  Medium.BaseProperties medium;
  SI.Energy nrg[Medium.nXi]; // Wrong unit on purpose. It should be mass
  
equation

  nrg = M*medium.Xi;
end TestDimAnalysis;

I don't see any warning with v1.16.0-dev-262-g58c7a5314 (64-bit)

I am using OpenModelica 1.16.0~dev-260-g390e593 on Ubuntu and this model throws following errors:

"Error: Too few equations, under-determined system. The model has 22 equation(s) and 25 variable(s).
[/usr/lib/omlibrary/Modelica 3.2.2/Media/Air/MoistAir.mo:61:5-61:72:readonly] Warning: Variable medium.p_steam_sat does not have any remaining equation to be solved in.
  The original equations were:
  Equation 17: medium.phi = medium.p * medium.Xi[1] / ((medium.Xi[1] + 0.6219647130774989 * medium.X_air) * medium.p_steam_sat), which needs to solve for medium.phi
  Equation 15: medium.x_sat = 0.6219647130774989 * medium.p_steam_sat / max(1e-13, medium.p - medium.p_steam_sat), which needs to solve for medium.x_sat
  Equation 3: medium.X_sat = min(medium.p_steam_sat * 0.6219647130774989 / max(1e-13, medium.p - medium.p_steam_sat) * (1.0 - medium.Xi[1]), 1.0), which needs to solve for medium.p
  Equation 2: medium.p_steam_sat = min(Modelica.Media.Air.MoistAir.saturationPressure(medium.T), 0.999 * medium.p), which needs to solve for medium.T
[/usr/lib/omlibrary/Modelica 3.2.2/Media/Air/MoistAir.mo:54:5-54:67:readonly] Warning: Variable medium.X_liquid does not have any remaining equation to be solved in.
  The original equations were:
  Equation 8: medium.R = 287.0512249529787 * medium.X_air / (1.0 - medium.X_liquid) + 461.5233290850878 * medium.X_steam / (1.0 - medium.X_liquid), which needs to solve for medium.R
  Equation 5: medium.X_steam = medium.Xi[1] - medium.X_liquid, which needs to solve for medium.X_steam
  Equation 4: medium.X_liquid = max(medium.Xi[1] - medium.X_sat, 0.0), which needs to solve for medium.X_sat
[/usr/lib/omlibrary/Modelica 3.2.2/Media/package.mo:4478:7-4479:50:readonly] Warning: Variable medium.Xi[1] does not have any remaining equation to be solved in.
  The original equations were:
  Equation 20: nrg[1] = M * medium.Xi[1], which needs to solve for nrg[1]
  Equation 19: medium.X[2] = 1.0 - medium.Xi[1], which needs to solve for medium.X[2]
  Equation 18: medium.Xi[1] = medium.X[1], which needs to solve for medium.X[1]
  Equation 17: medium.phi = medium.p * medium.Xi[1] / ((medium.Xi[1] + 0.6219647130774989 * medium.X_air) * medium.p_steam_sat), which needs to solve for medium.phi
  Equation 16: medium.x_water = medium.Xi[1] / max(medium.X_air, 1e-13), which needs to solve for medium.x_water
  Equation 7: medium.h = Modelica.Media.Air.MoistAir.specificEnthalpy_pTX(medium.p, medium.T, medium.Xi), which needs to solve for medium.h
  Equation 6: medium.X_air = 1.0 - medium.Xi[1], which needs to solve for medium.X_air
  Equation 5: medium.X_steam = medium.Xi[1] - medium.X_liquid, which needs to solve for medium.X_steam
  Equation 4: medium.X_liquid = max(medium.Xi[1] - medium.X_sat, 0.0), which needs to solve for medium.X_sat
  Equation 3: medium.X_sat = min(medium.p_steam_sat * 0.6219647130774989 / max(1e-13, medium.p - medium.p_steam_sat) * (1.0 - medium.Xi[1]), 1.0), which needs to solve for medium.p
  Equation 1: medium.MM = 1.0 / (34.52428788658843 + 20.98414717520355 * medium.Xi[1]), which needs to solve for medium.MM
"

I have not looked too deep into your model but this error seems about right.

NOTE: Unit checking is not activated by default. You can activate frontend unit checking with -d=frontEndUnitCheck if you use the new frontend or -d=oldFrontEndUnitCheck if you use the old one. There also is a backend module for unit checking which you can activate with --preOptModules+=unitChecking. The module at hand seems to break before any of those modules can be applied.

You can test the flags with this simple Module:

model TestDimAnalysis
 import SI = Modelica.SIunits;
 SI.Mass M;
 SI.Energy E; // Wrong unit on purpose. It should be mass
equation
  E = sin(time);
  M = E;
end TestDimAnalysis;

With the new frontend unit check i get:

[1] 22:05:20 Translation Warning
[TestDimAnalysis: 11:3-11:8]: The following equation is INCONSISTENT due to specified unit information: M = E

[2] 22:05:20 Translation Warning
The units of following sub-expressions need to be equal:
- sub-expression "E" has unit "J"
- sub-expression "M" has unit "kg"

With the backend unit checking i get:

[1] 22:06:59 Translation Warning
The following equation is INCONSISTENT due to specified unit information: M = E
The units of following sub-expressions need to be equal:
- sub-expression "E" has unit "J"
- sub-expression "M" has unit "kg"

I am not quite sure why one should prefer one over the other but the frontend is newer so i would recommend using that.

comment:17 by Francesco Casella, 5 years ago

For the record, the "Check" operation of OMEdit (Windows and Linux) invokes unit checking automatically. The "Simulate" operation doesn't.

The rationale is that unit checking is a bit slow, so we only do that upon checking (which is done when the model is written and tested), not when you simulate it, particularly in the case of large models.

comment:18 by Anton.Soppelsa@eurac.edu, 5 years ago

Dear all,

regarding point 2, I confirm that my model had problems. Still, I have the feeling that better diagnostic from the compiler would have saved me much time. After revision of the code and new experience I did developing few components of my library, I think that OMC was more correct than Dymola in refusing to run the model. I have not understood why and how Dymola could.

However, as I did much progress with the development of my library, I can't easily reproduce the exact same problem any more. Instead, I could submit different examples with slightly different error messages if you think it is useful, but probably that sort of comments have been already made long ago or it is really matter of understanding better the field of computational fluid dynamics.

From my side you can close this ticket.

Sincerely,

Anton

comment:19 by Adrian Pop, 5 years ago

Resolution: → fixed
Status: new → closed

All the issues are solved in this ticket.
If there are new issues we will open a new ticket.
Closing.

Note: See TracTickets for help on using tickets.