The following section contains a list of parameters and descriptions.
The table was taken from the original record pumpTableFlowHeadCharacteristicRecord. It defines the maximum and minimum pump curves for a given volume flow rate in m³/h. The columns are as follows:
Using pump speed to control pump power instead of using pump head (maxMinHeight) is more meaningful for the new speed controlled pump. Also this is how it would be implemented in a regular pump. It defines the maximum and minimum pump speed curves for a given volume flow rate in m³/h. The columns are as follows:
In order to limit the electric power consumption of the pump the speed needs to be reduced for high volume flow rates.
"maxMinSpeed" refers to the original "maxMinHeight" parameter name. The Addition "Curves" should reflect that this is a matrix/table and not a scalar. This should reduce confusion in the presence of the two parameters nMin and nMax which only contain the absolute minumum and maximum speeds. Those parameters can be used in a controller where limits are given as scalar parameters for example.
Notice that the default data have a range of 0 <= Q <= 10 m³/h! These values might be used in the models, for example in the form max(pumpParam.maxMinSpeedCurves[:,1]) for initialization or nominal values. So take care that the table data really fit to your pump to avoid strange behaviour.
This table contains measurement data of volume flow (Q), pump head (H), power consumption (P), pump speeds real and setpoint (N) as well as the corresponding pump head as calculated by the abc-formula for reference. From this data the coefficients can be calculated and it can be verified that the pump data in the record all belong together. From this data one can also directly derive the maxMinHeight table.
The original pump model used polynomial functions of higher order in two dimensional space. For example the pump head could be calculated as a function of volume flow rate and pump speed:
H = f(Q, n)=sum(c(i,j)*Q^i*n^j)
with i and j being non-negative Integers. The functions were written down directly for each pump type as a replaceble function for example:
H := 0.1041 - 1.168*Q - 0.0002526*n - 0.01049*Q^2 + 0.002589*Q*n + 5.614e-007*n^2 ...
In the current record only stores the coefficients for the functions:
A special type of formula has been "developed" for stability reasons. High order polynomials showed a good agreement with real pump data but lead to instable simulations (especially initialization) in certain situations. It was not clear what exactly would cause initialization problems with the high order polynomials but that low order polynomials could solve that problem with the disadvantage of lower acuracy of the pump curves. For example:
H= a*n^2+b*Q*n+c*Q^2"
Using the c[i,j]-matrix this would become:
H= c(0,2)*n^2+c(1,1)*Q*n+c(2,0)*Q^2
Therefore, the ABC-Formula emerges as a special case out of the
general formulation. In order to implement the latter formula
directly to speed up the computation and also allow to switch between
the precise and the not so precise pump curves without creating a
second record for the same pump, there is a second set of
coefficients:
Note that the computation of power must not be simplified as this is only a display variable in our simulations - no other states depend on power. Setting the default to [0,0,0] allows to check upon initialization if the selected coefficients can be used for simulation. So if the record misses a redeclaration of cABCeq and those coefficiens were selected be used, then an assert-warning will inform the user that with this record the selected calculation method (abc-formula) cannot be used. The same holds true for the matrix cHQN for example - it cannot be used if all the coefficients are at the default of zero.
There are no coefficients for the inverse function N = f(Q, H) as the inverse can be calculated with the p-q-formula from cABCeq:
n_1 = -b*Q/(2*a)+sqrt((b*Q/(2*a))^2 +(H-c*Q^2)/a)
n_2 = -b*Q/(2*a)-sqrt((b*Q/(2*a))^2 +(H-c*Q^2)/a)