Inconsistent Equation in Machines Library

[WernerWaho]

Hi, I opened a new issue to follow up the issue that I was facing in my past post and the possiblity o someone checking the Machine library.

"Originally posted by @perost in https://github.com/OpenModelica/OpenModelica/issues/7556#issuecomment-860599181

Perhaps I was a bit hasty, I missed that you had a second issue with the unit checking. That might not be your fault, it could be an issue with the unit checking or the library itself. I'll see if I can get someone who knows more about such issues to take a look. "

[WernerWaho]

With the valuable help of Perost I fixed the model, which I attach but have the issue of having 1 variable more as equations. Maybe the issue still lies in the "machines" library unit checking ?
Prufstand1.txt

The error references to the machines library in the following line ( 328) <final parameter SI.Position delta_head_init = flowCharacteristic(V_flow_single_init*1.1)-flowCharacteristic(V_flow_single_init) "Delta head for a 10% increase of flow at the initialization point";>

I checked already that all systems are properly defined. To my understanding for the fixed flowrate pump I only need to define the nominal flow rate and the desired nominal Pressure in the outlet. Or not ?

Is there any recomended guide for specific libraries where one can find recomended setup for all its options (as true/false) given some escenario ?

Thank you very much for your help.

[casella]

@perost, the flowCharacteristic function is defined in Modelica.Fluid.Machines.BaseClasses.PartialPump as

  replaceable function flowCharacteristic =  PumpCharacteristics.baseFlow;

which has the following definition

partial function baseFlow "Base class for pump flow characteristics"
  extends Modelica.Icons.Function;
  input SI.VolumeFlowRate V_flow "Volumetric flow rate";
  output SI.Height head "Pump head";
end baseFlow;

As you can see, the function output has type SI.Height, i.e. unit ='m'. I don't know why the NF believes it has unit 'm/s3', I guess that's a bug.

Could you please check?

@WernerWaho, it would be nice if you could attach a .zip file with your test case model, so @perost can check it easily.

[ghost]

the elements in your problem are defining the pressure drop/rise. There is no definition of the absolute pressure in the system. With an additional equation you can solve the problem.

equation  
  pipe3.port_a.p = 100.0;  // only a proposal

maybe in the Fluid-library there is an element available for the same purpose (e.g. in Electrical systems there is Ground element to do this).

In the next step you should define/check all start values based on the element parameters and problem constraints.

XXX in the meantime @casella added a comment. So my answer could be outdated.

[perost]

@perost, the flowCharacteristic function is defined in Modelica.Fluid.Machines.BaseClasses.PartialPump as

  replaceable function flowCharacteristic =  PumpCharacteristics.baseFlow;

which has the following definition

partial function baseFlow "Base class for pump flow characteristics"
  extends Modelica.Icons.Function;
  input SI.VolumeFlowRate V_flow "Volumetric flow rate";
  output SI.Height head "Pump head";
end baseFlow;

As you can see, the function output has type SI.Height, i.e. unit ='m'. I don't know why the NF believes it has unit 'm/s3', I guess that's a bug.

Could you please check?

The output does have the unit m in the flat model, but the unit checking warning is referencing V_flow which does indeed have the unit m3/s. But I don't understand what the unit checking is doing in this case.

[casella]

Yeah, sorry, understanding that error message is hard, there are endless fully qualified variables with long German names, lots of parentheses, and my parsing abilities are somewhat limited. Besides, the default font size of the error messages is impossibly small and my eyesight is no longer good as it used to be 😄

Looking closer, it seems that the unit checking is not complaining about the units of the function output, but rather about the unit of the function input. The formal function input Keimprufstand1.Pumpe_Qfixed.flowCharacteristic.V_flow is correctly reported to have unit "m/s3", as per the previously reported function declaration. Unfortunately, the actual function input Pumpe_Qfixed.V_flow_single_init is incorrectly reported to have unit "m". It should have unit "m3/s", since the parameter definition in the base class PartialPump is

  final parameter SI.VolumeFlowRate V_flow_single_init = m_flow_start/rho_nominal/nParallel
      "Used for simplified initialization model";

@perost, does this help you figuring out what's going wrong?

[perost]

Unfortunately, the actual function input Pumpe_Qfixed.V_flow_single_init is incorrectly reported to have unit "m". It should have unit "m3/s", since the parameter definition in the base class PartialPump is

It has the correct unit in the flat model at least. But the unit checking is complaining about the expression Pumpe_Qfixed.V_flow_single_init * 1.1 and not the parameter itself, though it seems to me like that shouldn't change the unit. Someone who understand how the unit checking algorithm works should probably take a look at that.

[casella]

the elements in your problem are defining the pressure drop/rise. There is no definition of the absolute pressure in the system.

True, but that's ok, as long as you have a compressible fluid and you properly define the initial conditions. See also an old paper of mine on the topic.

With an additional equation you can solve the problem.

equation  
  pipe3.port_a.p = 100.0;  // only a proposal

This looks a bit of a hack to me. If you want to keep the pressure fixed, you should connect a fixed pressure source to the circuit, or possibly a hydraulic accumulator. Not throw in an extra equation.

Modelica.Fluid components are balanced. If they are properly connected, it can be proven that the resulting systems are always balanced. See also Section 4.7 of the Modelica Specification.

The problem here is the unconnected valve connector.

@perost, @kabdelhak, shouldn't we issue a warning if we have an unbalanced system model where some components have unconnected input connectors? (mind you, not unconnected connector inputs, those are fine, see Section 4.7).

maybe in the Fluid-library there is an element available for the same purpose (e.g. in Electrical systems there is Ground element to do this).

Yes, it's the fixed pressure source 😄

[casella]

It has the correct unit in the flat model at least. But the unit checking is complaining about the expression Pumpe_Qfixed.V_flow_single_init * 1.1 and not the parameter itself, though it seems to me like that shouldn't change the unit.

In fact, I understand that multiplying a variable by a literal should make the unit checking impossible, because currently that literal is considered to have unit = "", i.e., unspecified unit. Hence, the product could have any unit.

I started MCP-0027 to fix this issue three years ago, but the discussion became very complicated and it just went nowhere.

Someone who understand how the unit checking algorithm works should probably take a look at that.

Yeah, I always forget who implemented that. @adrpo, can you please comment on this?

[WernerWaho]

Hi Again,

I have tried to refine my model following the recomendations of the output files mainly about initialization conditions, that I got when simulating. However I keep getting the same error about the pump. Maybe I should insert a step signal to start up the pump ? I attach the model in zip with a couple output files and look forward for any comment on your side.

Thank you very much in advance :)

Prufstand Model.zip

[WernerWaho]

Good Morning,

another solution that I tested is implementing the closed system initializer proposed in your article @casella on a model with Prescribed Pump, following very similar configurations as in the PumpingSystem example.

However I get the following error

`[1] 13:16:05 Symbolic Error Too few equations, under-determined system. The model has 418 equation(s) and 419 variable(s).

[2] 13:16:05 Symbolic Warning [ClosedSystemInitializer: 15:3-15:65]: Variable Init.initialConditionResidual does not have any remaining equation to be solved in. ` which is strange because in the Initializer I do have an equation explicitly stating: 0 = initialConditionResidual, and that initializator has 3 variables and 3 equations, and the base model without the initializer has 415 equation and 415 varibles. I wonder where is the additional variable comming from.

I guess the issue in this Initializer is how I make the connection to it, between the pipe and the inlet to the pump. I don´t really understand how to connect it properly. The article states "When instantiating the model, the extra initial condition can be specified by connecting a RealExpression block containing its residual to the component’s input port." but this is still unclear and I tried a simple connect equation to the ports of this element.

@casella Can you please explain how should I integrate this Initializer into the model ? I´d appreciate it.

Prufstand Model.zip