changed Buildings.Fluid.Movers.BaseClasses.Characteristics.power:

[Mathadon]

Hi,

I made the following changes:
Similarity law now uses a working point based on a rotational speed V_flow/r_N instead of V_flow. Only when referring to this working point then the power law P2= r_N^3*P1 is valid.

I have some images that can serve as a limited validation. The graphs you see are from the data sheets from real pumps.
Before:



After:

Also, for the following figures I changed the power law from:
P:=r_N^3_Buildings.Utili ....
to
P:=r_N^2.75_Buildings.Utili ....

This seems to give even better results:



Although not related to the similarity laws, this behavior can be explained by the fact the electrical motors usually become more efficient for higher powers and that this is not reflected in the power law. Is there a way this can be implemented in the buildings library as well?

Kind regards,

Filip

[Mathadon]

Should I have added author information? Please let me know if I need to change things :)

Filip

[mwetter]

Is there a physical rationale for the change

       P:=r_N^3*Buildings.Utilities.Math.Functions.cubicHermiteLinearExtrapolation(
 -                  x=V_flow,
 +                  x=rat,
                    x1=data.V_flow[i],
                    x2=data.V_flow[i + 1],
                    y1=data.P[i],

cubicHermiteLinearExtrapolation is a polynomial that is fitted to the variable V_flow to produce P, but then your model evaluates this polynomial for V_flow/r_N. Is there any rational that would justify evaluating the polynomial for an independent variable that is different from the one for which it was generated? Your data happen to give a better fit with your change, but did you also verify this with another manufacturer? Evaluating a polynomial for a different independent variable seems questionable to me.

If there is really a dependency on r_N that seem to be better with a different formulation, then it may be better to have some formulation like

 P:= r_N^3 * eff(r_N) * Buildings.Utilities.Math.Functions.cubicHermiteLin...

Note that rat:=V_flow/max(r_N,0.1); would need to be regularized to avoid a discontinuous derivative.

[Mathadon]

Yes there is a physical rationale for this change. Allow me to (try to) explain based on this figure:

Source: http://www.engineeringtoolbox.com/affinity-laws-d_408.html

Similarity laws hold for two similar working points. Consider state 1 (nominal speed) and state 2. For these states the following equations hold:
eta1=eta2
q1/q2 = n1/n2
dp1/dp2 = (n1/n2)^2
P1/P2 = (n1/n2)^3

So in the code the last equation is used. For this equation to hold you must evaluate P1 based on its working points q1 and dp1 as if it were running at nominal speed. Right now you use q2 te evaluate P1, which should be q1 = q2/r_N. You can see this also from the figure where the different working points have different mass flow rates.

Another way to show this:
P2 = q2*dp2/eta2 = (n2/n1)^3 * dp1 * q1 / eta1 = (n2/n1)^3 * P1(q1)

The way my adjustment works is to evaluate the polynomial as if it were running at the rotational speed for which it was constructed and then transforms the result to the correct rotational speed.

Note that for similar working points the efficiency is the same (see above) and therefor using a term such as eff(r_N) does not really make sense to me.

I did not check with different manufacturers but I did check for two different types and three different sizes of pumps. I also have a fourth example where similarity laws somehow do not seem to hold (regardless of the adjustment):

Regarding your last comment:
I suppose I should then use: Buildings.Utilities.Math.Functions.smoothMax ?
I chose the 0.1 value arbitrarily to avoid division by zero. The problem is that for very low rpms (< 10 %) this approximation becomes wrong so it could be lowered further. However, I doubt similarity laws are still accurate at these rpms anyway.

[mwetter]

I agree with this change and will merge it to the master.

[mwetter]

Filip, can you please add an example in Buildings.Fluid.Movers.Examples that reproduces one of the charts you showed above and also attains zero volume flow rate. This will then become part of the unit tests.
I made some changes and posted the latest code on https://github.com/lbl-srg/modelica-buildings/tree/Mathadon-develop

[Mathadon]

woops, deleting branches causes problems here..
Anyway, I added a new pull request. I am not sure what you mean by reaching zero volume flow rate. Right now there are pumps in series so that the volume flow rate is forced to become zero. Is this what you mean?

Unfortunately you cannot exactly generate the graphs from the file I added. I use a Python script for this myself. Plotting output_y should however give close results.
fyi: I will be attending the Modelica conference + annex 60 meeting so there's a possibility to discuss this further later on.

[mwetter]

Thanks for the updated pull request. I am revising the code, but most
likely will complete it after the Lund meeting.

Michael

On Thu, Feb 27, 2014 at 4:01 AM, Filip notifications@github.com wrote:

woops, deleting branches causes problems here..
Anyway, I added a new pull request. I am not sure what you mean by zero
volume flow rate. Right now there are pumps in series so that the volume
flow rate does become zero. Is this what you mean?

You cannot easily generate the graphs from the file I added. I use a
Python script for this myself.
fyi: I will be attending the Modelica conference + annex 60 meeting so
there's a possibility to discuss this further later on.

Reply to this email directly or view it on GitHubhttps://github.com//pull/202#issuecomment-36235021
.

[Mathadon]

Hi @mwetter

I think that the problem described above for FlowMachine_Nrpm also applies to FlowMachine_m_flow and FlowMachine_dp. Right now the efficiency/power is calculated based only on r_V, the pump speed is not taken into account.

In think N should first be calculated from m_flow and dp. From this N, r_N can then be calculated and this would allow to calculate the efficiency in a way similar to FlowMachine_Nrpm.

I overlooked this in ibpsa/modelica-ibpsa#56 but better late than never..

Fixing this may however prove difficult since N needs do be calculated from the discretised relation V_flow = f(dp) and the similarity law equations.

Filip

[mwetter]

This has been merged to the development branch lbl-srg:issue209_pumpRecords rather than the master, see #285.

@Mathadon : can you please explain what the problem is with "Right now the efficiency/power is calculated based only on r_V, the pump speed is not taken into account." Do you suggest to redefine the signature of the motor and hydraulic efficiency functions? If so, how do you propose them?

[Mathadon]

A more elaborate explanation:

Source: http://www.engineeringtoolbox.com/affinity-laws-d_408.html

Similarity laws hold for two _similar_ working points. Consider state 1 (nominal speed) and state 2. For these states the following equations hold:
eta1=eta2
q1/q2 = n1/n2   (or m_flow1/m_flow2 = n1/n2)
dp1/dp2 = (n1/n2)^2
P1/P2 = (n1/n2)^3

In this case we have eta1 = f1(r_V1) for n = n1 (the nominal curve) and f1 known
we would like to know eta2 = f2(r_V2) for n = n2, with n2 and f2 unknown.

Since f2 is unknown we would like to use eta1 = eta2 = f1(r_V1). This is only valid if the two working points are similar so we also require:
eqn1: q1/q2 = n1/n2
eqn2: dp1/dp2 = (n1/n2)^2

furthermore we have:
eqn3: dp1=f3(q1) with f3 a known function

we know n1 (nominal rpm), q2 (mass flow rate setpoint), dp2 (from load), so unknowns are n2, q1 and dp1. They can be solved from equations 1,2,3. Knowing q1, then r_V1 can be calculated and from this eta1= eta2 = f1(r_V1). The power can be calculated in a similar way.

I am however unsure of how to solve this using the existing 'piecewise' functions but it may be sufficient to plug the above equations in Modelica. Note that this complicated system does not need to be solved in pump_Nrpm since there you explicitly set n2, which simplifies things.
@damienpicard can you confirm my reasoning above just to be sure?

Fyi: I have been working on a pump model that explicitly contains equations 1, 2, 3 where equation 3 is a polynomial but numerically it can be quite difficult to solve. I managed to improve this a bit by using n2 as a state, which corresponds to a physical impeller inertia but introduces a small time constant. Let me know if this is of interest?

Kind regards!

Filip

[mwetter]

@Mathadon : I suggest you write up on 1 or 2 pages what changes you specifically propose, and propose an example implementation. The explanation above is quite confusing and I would have to speculate what you mean, rather than clearly understand what the change proposal is.

Inverting a polynomial is something we rather don't do unless we know for sure (i.e., can prove) that there is only one solution. Otherwise, the solver will fail in some situations. Also, adding a fast transient is not desirable as FlowMachine_dp and FlowMachine_m_flow are meant to be used in coarse simulations where speed is important. Otherwise, one would probably use FlowMachine_y or FlowMachine_Nrpm.

[damienpicard]

According to me, the reasoning of Filip is right. However, the solver will need to solve a set of non-linear equations including the polynomial. Some investigations of the uniqueness of the solution should be done.