MSL 3.2.1 build 4 - Fluid pump efficiency

[modelica-trac-importer]

Reported by victor.avila on 28 Jan 2016 08:56 UTC In the model SimpleMSLpump.mo, one simple MSL pump and two boundaries were connected to each other. When I run the simulation in Dymola2016FD01, I got these statistics:

Translated Model Constants: 68 scalars Free parameters: 50 scalars Parameter depending: 38 scalars Outputs: 2 scalars Continuous time states: 2 scalars Time-varying variables: 24 scalars Alias variables: 54 scalars Number of mixed real/discrete systems of equations: 0 Sizes of linear systems of equations: { } Sizes after manipulation of the linear systems: { } Sizes of nonlinear systems of equations: {10} Sizes after manipulation of the nonlinear systems: {2} Number of numerical Jacobians: 1

Initialization problem Sizes of nonlinear systems of equations: {10} Sizes after manipulation of the nonlinear systems: {2} Number of numerical Jacobians: 1

How can the efficiency of the MSL pump be improved? I mean, getting rid of non-linear equations and jacobian.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1898

[modelica-trac-importer]

Modified by dietmarw on 28 Jan 2016 13:56 UTC

[casella]

Unfortunately the attachment was lost due to the migration from trac.modelica.org to github.com of the bug tracking system. I assume the two boundaries were fixed pressures. The pump model is based on an explicit head = f(volume_flow) equation, because that's how the behaviour of pumps is usually specified. So, if you prescribe the two pressures at the boundary (i.e., the head) you need to solve this implicit numerically for the volume flow rate.

I'm not sure who the other iteration variable might be (you report two iteration variables after tearing), but I guess it could be due to the default system object settings that allow flow reversal, which may introduce additional nonlinear relationships because the density depends on the enthalpy, that depends on the flow direction. If you change that setting to false, you may end up with just one unknown, i.e., the pump flow. In that case, Dymola may also be able to compute the jacobian analytically, which is probably too complicated if flow reversal is allowed.

Feel free to open another ticket with an updated example if the suggested action is not sufficient to solve the issue (which is also, at least partially, a tool issue, not a library issue)

[beutlich]

@casella @claytex I retrieved the original attachment from https://trac.modelica.org/Modelica/attachment/ticket/1898 and attached it above.

[casella]

I ran the test case with Dymola and I can basically confirm my former diagnosis. The two iteration variables are

• pump.medium.T
• pump.port_a.m_flow

and the two residual equations are the pump head-mass flow relationship and the energy balance

  0 = pump.head-homotopy((pump.N/pump.N_nominal)^2*pump.flowCharacteristic_Unique'"pump"'
    (pump.V_flow_single*pump.N_nominal/pump.N, {1.36E-005, 5.56E-005, 
    0.0001112, 0.0001668, 0.0002224, 0.000278, 0.0003336, 0.0003753}, {
    4.334143, 3.93096389, 3.4404372, 2.855833, 2.3115477, 1.7202237, 
    1.1490489, 0.7525957}), pump.N*(pump.flowCharacteristic_Unique'"pump"'(0,
     {1.36E-005, 5.56E-005, 0.0001112, 0.0001668, 0.0002224, 0.000278, 
    0.0003336, 0.0003753}, {4.334143, 3.93096389, 3.4404372, 2.855833, 
    2.3115477, 1.7202237, 1.1490489, 0.7525957})+pump.V_flow_single*(if abs(
    pump.V_flow_single_init) > 0 then pump.delta_head_init/pump.V_flow_single_init
     else 0))/pump.N_nominal);
  0 = pump.Hb_flow-pump.port_a.m_flow*boundary.ports[1].h_outflow+
    pump.port_a.m_flow*pump.port_a.h_outflow;

I tried setting allowFlowReversal = false in the system object but this didn't help. In principle, once flow reversal has been excluded, it should be possible to compute rho as a function of fixed variables, but apparently the tool cannot figure this out.

You should contact your tool vendor to discuss why this happens, as well as why a symbolic Jacobian cannot be obtained in this case.

[HansOlsson]

@casella wrote "In principle, once flow reversal has been excluded, it should be possible to compute rho as a function of fixed variables, but apparently the tool cannot figure this out."

Note that rho and temperature cannot be directly computed but are part of a non-linear system of equations that depends on the pressure drop (which as default is zero).

Note that is a static system - separate from pump speed.

For the default configuration (1.01325 bar) the temperature is 20degC and rho is 1.04257216 g/cm3 If boundary1.p is changed to 1.015 bar it seems the temperature becomes 20.00005degC and rho 1.04256718 g/cm3. That system of equations also seems ill-conditioned in various way; and it doesn't seems physical to indirectly determine the temperature in this way for the pump.

[HansOlsson]

To explain that rho cannot directly be computed consider the relevant equations (removing homotopy and using f1 and f2 for the polynomial functions):

pump.rho=f1(pump.medium.T);
pump.V_flow=pump.port_a.m_flow/pump.rho;
pump.V_flow_single=pump.V_flow/pump.n_parallel;
pump.W_single=1.25*pump.dp*pump.V_flow_single;
pump.Hb_flow=-pump.W_single*pump.nParallel;
pump.port_a.h_outflow=f2(pump.medium.T);
pump.Hb_flow=pump.port_a.m_flow*(boundary.ports[1].h_outflow-pump.port_a.h_outflow);

Here pump.n_parallel, pump.dp and boundary.ports[1].h_outflow are known; and pump.port_a.m_flow is unknown - but we can divide V_flow, V_flow_single, W_single, Hb_flow by pump.port_a.m_flow and substitute in the last equation to get a static non-linear equation:

-1.25*pump.dp/f1(pump.medium.T)=(boundary.ports[1].h_outflow-f2(pump.medium.T))
with pump.rho=f1(pump.medium.T);

Determining the temperature from the pressure drop between the reservoirs seems odd to me; I don't know if this is due to settings for the pump-model or whether the entire scenario is odd.

In the default case the pressure drop is zero so a solution is that the temperature is the same as the boundary-temperature - and thus the density can be computed. However, both dividing by time-varying mass-flow and evaluating the pressure drop to determine the temperature is excessive.

I don't know if and how the model could be rewritten to expose the variables divided by mass-flow; but it doesn't seem like an invalid issue. (It could be that this part is something we just have to accept.) (Will return to the Jacobian issue.)

[HansOlsson]

Part of the Jacobian issue is related to the pump-characteristics lacking derivative-information; but there is more to it.

However, there is more to the Jacobian-issue (have not fully analyzed it) - and I don't see that we should rush it for the coming release.

[casella]

In fact, if you take into account the enthalpy increase between the inlet and the outlet due to the pump work, it is not odd at all that there is a relationship between dp and T: the higher dp, the higher the fluid enthalpy, the higher the temperature

My 2 cts

[HansOlsson]

In fact, if you take into account the enthalpy increase between the inlet and the outlet due to the pump work, it is not odd at all that there is a relationship between dp and T: the higher dp, the higher the fluid enthalpy, the higher the temperature

I agree that the effect will be there, but I am not sure whether we are including the most relevant aspects of the pump - or whether we are focusing on a minor issue and missing larger effects.

If we are missing larger effects I don't know if that is a defect of the MSL models or of the parameters in this example.

However, if the example makes sense - then we would need to consider if we could enhance the model to in some way reformulate the equations to divide by m_flow so that the temperature can more easily be statically determined, since I don't think we should require that tools do the derivations I presented above to deduce that temperature can be statically determined.

Obviously we can also say that it would be too complicated and live with this part of the issue.

(The Jacobian enhancement is clearer and separate.)

[casella]

If the working fluid is water, the temperature increase is negligible, so one could have a simplified model where Hb_flow is set to zero.

However, if the working fluid is air, then you get about 1 K for each 1000 Pa of dp. I'm not sure whether this is relevant or not for the typical applications of the library (cooling circuits), @AHaumer, @christiankral can you comment on that?

[beutlich]

@casella @HansOlsson @christiankral @AHaumer Unfortunately the discussion was stopped after valuable analyses. Could you please decide how to proceed and if MSL v4.0.0 seems possible?

[casella]

@casella @HansOlsson @christiankral @AHaumer Unfortunately the discussion was stopped after valuable analyses. Could you please decide how to proceed and if MSL v4.0.0 seems possible?

Do you mean getting this resolved in v4.0.0?

[beutlich]

Do you mean getting this resolved in v4.0.0?

Exactly.