Movers with integrated pressure drop

[Mathadon]

Valves have a parameter dpFixed_nominal that allows to incorporate fixed pressure drops into a single equation. This allows to reduce sizes of non-linear systems.

It would be nice to have something similar for the mover models.

[mwetter]

This could be added quite easily by adding a block before the input signal for preSou.dp. I wonder however whether this really leads to fewer equations compared to using a pressure drop model at the fan outlet and setting from_dp = false which is the default. Packaging it into the mover would however make the configuration easier for the user.

For FlowControlled_m_flow, no changes would be needed.

However, why do you think this leads to fewer equations? I deleted in Fluid.Movers.Examples.ClosedLoop_y the pressure drop element at the inlet which reduces the size of the nonlinear equations, then I deleted the pressure drop at the outlet, which does not further reduce the size of the nonlinear equations. From this I conclude that adding a pressure drop at the mover outlet does not increase the size of the nonlinear equations. Do you have another case that shows that your proposed change indeed leads to fewer equations?

[Mathadon]

Regarding Fluid.Movers.Examples.ClosedLoop_y. I do not entirely agree with your analysis.

The difference between the pressure drop component at the inlet and the one at the outlet should not exist. The fact that there is a difference is because the fan model currently has a pressure state by default since the used air medium is compressible. This fixes the mixing volume pressure to a certain value and therefore splits the pressure flow network in two parts. If you set massDynamics = steadyState in the MixingVolume then you get:

Sizes of nonlinear systems of equations: {7}
Sizes after manipulation of the nonlinear systems: {1}

when disabling the first pressure drop component you get:

Sizes of nonlinear systems of equations: {3}
Sizes after manipulation of the nonlinear systems: {1}

    dp2.dp := IDEAS.Fluid.BaseClasses.FlowModels.basicFlowFunction_m_flow( -
      sou.ports[1].m_flow, 0.006324555320336759, 0.03);
    fan.VMachine_flow :=  -sou.ports[1].m_flow/fan.rho_in;

  equation // Residual equations
    0 = dp2.dp-IDEAS.Fluid.Movers.BaseClasses.Characteristics.pressure(
      fan.pCur1, 
      fan.VMachine_flow, 
      fan.y_actual, 
      fan.VDelta_flow, 
      fan.dpDelta, 
      0.16666666666666669, 
      1000.0, 
      fan.preDer1, 
      fan.delta, 
      fan.cBar, 
      fan.kRes);

when disabling the second pressure drop component you get:

Sizes of nonlinear systems of equations: {6}
Sizes after manipulation of the nonlinear systems: {1}

  algorithm // Torn part
    dp1.dp := IDEAS.Fluid.BaseClasses.FlowModels.basicFlowFunction_m_flow( -
      sou.ports[1].m_flow, 0.006324555320336759, 0.03);
    dp1.port_b.p := sou.p-dp1.dp;
    fan.rho_in := smooth(5, 1.1843079200592153E-05*dp1.port_b.p);
    fan.VMachine_flow :=  -sou.ports[1].m_flow/fan.rho_in;
    fan.dpMachine := IDEAS.Fluid.Movers.BaseClasses.Characteristics.pressure(
      fan.pCur1, 
      fan.VMachine_flow, 
      fan.y_actual, 
      fan.VDelta_flow, 
      fan.dpDelta, 
      0.16666666666666669, 
      1000.0, 
      fan.preDer1, 
      fan.delta, 
      fan.cBar, 
      fan.kRes);

  equation // Residual equations
    0 = fan.dpMachine-sou.p+dp1.port_b.p;

here the difference is caused again because air is compressible and this means its density rho_in depends on the pressure in the mixing volume, which is fixed to the boundary pressure when the first pressure drop component is removed, allowing the value to be pre-computed.

This actually suggests that it may be wise to foresee an option for using a default value for the computation of rho_in..?

Now, suppose we change the code of the mover to include the pressure drop equation then we should go from 3 to 2 equations since we should get:

    fan.VMachine_flow :=  -sou.ports[1].m_flow/fan.rho_in;

  equation // Residual equations
    0 = IDEAS.Fluid.BaseClasses.FlowModels.basicFlowFunction_m_flow( -
      sou.ports[1].m_flow, 0.006324555320336759, 0.03) -IDEAS.Fluid.Movers.BaseClasses.Characteristics.pressure(
      fan.pCur1, 
      fan.VMachine_flow, 
      fan.y_actual, 
      fan.VDelta_flow, 
      fan.dpDelta, 
      0.16666666666666669, 
      1000.0, 
      fan.preDer1, 
      fan.delta, 
      fan.cBar, 
      fan.kRes);

this in itself probably does not lead to speedups, but it should do when connecting multiple of these components in parallel, since dymola will then be able to identify the common pressure drop over the components.

edit: I was wrong since this would require to set from_dp=true, which we probably won't add (see #474 ) this option. So right now there may not be an added value indeed. But I do suggest to simplify the density calculation.

edit2: what you could do, is offset the pressure drop characteristic in parameter Buildings.Fluid.Movers.BaseClasses.Characteristics.flowParametersInternal pCur2, such that only one pressure drop function needs to be evaluated. But that may be a bit too involved..

[mwetter]

How and why would you simplify the density calculation? Using a constant density for air would lead to large errors in typically HVAC systems.

[Mathadon]

I think the temperature-dependence of the density is larger than the pressure-dependence? The pressure range in a HVAC system is around 1000 Pa compared to 100.000 Pa, while the temperature range is 40 K out of 300 K. We already simplify the density-dependence of the temperature in Annex60.Media, so I imagined that we could do without the pressure-dependence too?

[mwetter]

Then what you propose is not using a default density, but rather using a density calculation with a default pressure? These are not the same because if a user select an ideal gas, then the density will be temperature dependent.

Can you point to a unit test where this simplification makes a difference? If this really speeds up the simulation noticeably, then the change is good, otherwise it just adds another level of complexity/assumptions to the mover models which already are rather complicated. If this is experimental, then I suggest to put it into an experimental branch until you have data that shows that a change leads to better simulation and warrants propagating the change to all four libraries.

[Mathadon]

I see your point. I actually did mean to use a default density, but your suggestion is better.

I'll try to find such an example later.