Conservation of energy in Modelica.Fluid (kinetic term)

[modelica-trac-importer]

Reported by fcasella on 23 Jan 2009 00:23 UTC
A few general considerations about the energy balance equations in Modelica_Fluid

The energy balance equation for 1D systems includes a term

d/dx(m_flow*(e + p/rho + u²/2 + gz))

which accounts for internal energy, pressure energy, kinetic energy, and potential energy. Let's consider for simplicity the equations of components with no storage and no heat or work added from the outside (i.e. PartialTwoPortTransport): the balance equation is then

d/dx(m_flow*(h + u²/2 + gz)) = 0

and m_flow is uniform from inlet to outlet (due to the mass balance equation). The equation can thus be integrated from port_a to port_b, giving

h_a + u_a²/2 + gz_a = h_b + u_b²/2 + gz_b

In many applications where there is significant heat transfer, the mechanical terms gz and u²/2 are negligible, compared to the changes in h due to heat transfer, so the equation is approximated as

h_a = h_b

which then becomes

port_a.h_outflow = inStream(port_b.h_outflow);
port_b.h_outflow = inStream(port_a.h_outflow);

However, there are cases where this terms might be significant (e.g. nozzles, vertical pipes), so it is interesting to check whether it would be possible to consider them in Modelica_Fluid without too much overhead.

The gravity term is no big deal, as it gives a constant contribution. Furthermore, if z_a-z_b = 0, it is easy to get rid of it by symbolic manipulation. So, we agreed to write these equations in PartialTwoPortTransport:

port_a.h_outflow = inStream(port_b.h_outflow) + g*(z_b-z_a); 
port_b.h_outflow = inStream(port_a.h_outflow) + g*(z_a-z_b);

The kinetic term is much more problematic, as it depends on the velocity, and thus on density, mass flow rate, and cross section at the port. The cross section might not be available in many cases (and usually not relevant either). Furthermore, the dependence on the mass flow rate would break the nice property of propagation of inStream enthalpy in series-connected flow models, by introducing nonlinear implicit equations for the stream enthalpy involving the mass flow rates. Finally, computing the velocity at both ports requires to always compute the port density, which might be not needed otherwise. Therefore, writing:

port_a.h_outflow = inStream(port_b.h_outflow) + g*(z_b-z_a) +
                   (u_b^2-u_a^2)/2;
port_b.h_outflow = inStream(port_a.h_outflow) + g*(z_a-z_b) +
                   (u_a^2-u_b^2)/2;

might not be convenient.

One possible solution is to define h_outflow on the ports as the so-called total enthalpy, or stagnation enthalpy, i.e. h + u²/2. In this way, the equations

port_a.h_outflow = inStream(port_b.h_outflow) + g*(z_b-z_a);
port_b.h_outflow = inStream(port_a.h_outflow) + g*(z_a-z_b);

are exact, and (total) enthalpy is propagated through chains of flow components without generating implicit nonlinear equations involving the mass flow rate.

For all the applications where u²/2 is negligible, one could use h_outflow directly to compute the thermodynamic properties of the fluid, thus ignoring the small difference between enthalpy and total enthalpy. In those special cases where the velocity is significant (e.g. a nozzle), it is possible to write

h_total = inStream(port.h_outflow);
state = Medium.setState_ph(port.p, h_total - u^2/2);

Of course this additional term could be made optional, so the additional numerical complication due to more coupled nonlinear algebraic equations is only included when necessary.

The advantage of this solution is that, while allowing exact results, the added complication is local to those few components where the velocity is relevant. Furthermore, the energy balance is always correct, while the approximation would just involve the computation of the thermodynamic state corresponding to a certain enthalpy.

The changes to the existing library are minor: a change to the description of the connector variables, and a few changes on those components which might have a significant variation of velocity between inlet and outlet.

---

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

[modelica-trac-importer]

Comment by rfranke on 23 Jan 2009 09:32 UTC
The current treatment by Modelica_Fluid with port.h_outflow defining the specific enthalpy and port.m_flow giving additional information about the kinetic energy (i.e. energy balance 2 equation) has several advantages. In particular medium propoerties can directly be calculated from variables communicated through ports. The models

  Vessels.SimpleTank
  Pipes.DynamicPipe(momentumDynamics<>Dynamics.SteadyState)

now treat kinetic energy based on this approach. Many other models ignore kinetic energy, which is sufficient for simple applications and might be usable more generally as well (e.g. a StaticPipe with constant cross flow area and no boundary heat transfer).

Unfortunately there finds some bad candidates in the library, e.g. ValveCompressible, ValveVaporizing and SuddenExpansion, that might require treatment of kinetic energy.

Before changing the overall connector design, it would be good to know, which improvement is achieved, compared to the current connector definition and the use of m_flow for kinetic energy.

Depending on the result we have several options

1. extend all flow models as no significant overhead is introduced (cf. potential energy, Ticket Placeholder #58)
2. extend all flow models and introduce an Advanced flag for kinetic energy
3. extend only critical flow models
4. change the connector definition if this offers advantages over other options based on the current connector definition

To strart with, it would be good to see what the treatment of kinetic energy would mean conceptionally and numerically for the bad candidates, like ValveVaporizing, see also Ticket #60.

[modelica-trac-importer]

Comment by fcasella on 23 Jan 2009 10:13 UTC
Comment by Martin Otter:

A very quick remark (since I do not have time to work this out now): Another alternative which was advocated by Hilding and me since 6 years is to remove all the mechanical terms from the energy balance (energy balance II). This is achieved by multiplication of the momentum equation and subtracting it from the energy balance. As a result, neither the gravity nor the kinetic energy term are longer present in the energy balance (this is exact in all situations without any compromize). The only small drawback is that some terms of the momentum balance appear in the energy balance (e.g. the dissipation work performed by the pipe friction). Intuitively, this means that the energy balance contains only the balance for the thermodynamic variables and the momentum balance contains only the balance of the mechanical terms. Neglections of terms are then performed in the momentum balance (static instead of dynamic), whereas the energy balance II is always used without any neglections.

My reply:

As far as I understand, energy balance I or II are completely equivalent, so that can play no miracle. In particular, energy balance II will not solve the main problem, i.e. breaking the chain of stream variables by adding nonlinear coupled equations. If you integrate energy balance II from port_a to port_b (assuming no diffusion and no heat or work from the outside), the two right-hand-side terms of energy balance II (v*A*dp/dx and vFf) will introduce a bad coupling in the stream enthalpy equation, something like:

port_b.h_outflow = inStream(port_a.h_outflow) + 
  1/rhomean(port_b.p-port_a.p) + 1/(rhomean*Amean)*Ff

Furthermore, if A and/or v change from port_a to port_b, it is impossible to integrate energy balance II exactly (mean values of v and A appear in the balance equation).

Martin's comment

I find it confusing to have h+u²/2 in the connector and depending on the component this might be interpreted as h. This is also not good for enhancements in the future, where shock waves might be treated. Here, vector quantities need to be taken into account, i.e., u is no longer a scalar but a vector.

My reply:

I guess using stagnation enthalpy is the only way to have enthalpy stream variables work efficiently. As to gasdynamics, I am really convinced that a different design of the library would be needed (and some expert in the group too...)

More comments welcome!

[modelica-trac-importer]

Comment by rfranke on 23 Jan 2009 20:31 UTC
Hmmm. Stream variables have three important features:

1. they can be propagated through multiple flow models, independent of the actual mass flow rate,
2. they mix in multi-way connections according to the flows carrying them,
3. they are different for each connector in a connection set, e.g. two tanks can directly be connected and still have different temperatures.
   It is obvious that these features do not only apply to specific enthalpy h, but also to mass fractions X and to trace substances C. It is not that obvious how they apply to the flow of kinetic energy.

If we don't introduce approximations too fast, like the ignoration of kinetic energy for the calculation of medium properties, aren't then the model equations basically the same, independent of the definition of connectors or the use of a particular formulation of the energy balance?

Do we really need to go back to the roots, in order to model a nozzle?

[modelica-trac-importer]

Comment by fcasella on 23 Jan 2009 21:51 UTC
On the contrary, the rigorous balance equation for a small connection volume (without storage) is:

sum(m_flow_j*(h_j + u_j²/2)) = 0

energy comes into the connection volume in the form of internal energy, work done by the moving fluid (the p/d term which goes into the specific enthalpy) and kinetic energy. No matter what happens in the mixing volume (friction, pressure change due to different port diameters, turbulence, phase change, anything), this balance equation is always true without approximation (save relativistic effects, but we definitely assume the u << speed of light).

So, I do insist that the correct interpretation of the semantics of stream variables in connections, which is derived from sum(port_j.m_flow) = 0 sum(port_j.m_flow_j * port_j.h_outflow) = 0

requires h_outflow to be defined as the total (or stagnation) enthalpy. Otherwise, we will be introducing approximations too fast...

[modelica-trac-importer]

Comment by rfranke on 24 Jan 2009 05:45 UTC
So you think there is nothing we can do, based on the current concept of Modelica_Fluid 1.0, in order to improve the treatment of kinetic energy by flow models like ValveVaporizing?

The least thing we must do is to update the documentation for models that obviously do not fulfill the general claim made in UsersGuide.ComponentDefinition.BalanceEquations. Having investigated this issue, could you please have a look?

[modelica-trac-importer]

Comment by fcasella on 24 Jan 2009 14:19 UTC
I try to summarize the current status.

There are two problems we have to discuss. One is how we write the equations of the component internally, the other one is how they are connected.

As to how we connect components, unless we change the concept of effort, flow and stream variables, there is no doubt that the connection equations are

sum(m_flow_j) = 0
p1 = p2 = ...
sum(m_flow_j*h_outflow) = 0

The first equation is the mass balance and it is always correct.

The second is a simplified momentum balance, which is correct only for one-to-one connections with equal diameters; otherwise an explicit fitting or junction is required, or errors of the order of the magnitude of rho*u²/2 will result in the pressures. Changing the definition to total pressure would not help, since it is not possible to formulate connection equations so that they account for friction effects for all connections which are not one-to-one equal diameter. We all agree this is ok.

As to the third equation, things are slightly different. If h_outflow is the specific enthalpy, then the equation is only correct for one-to-one connection with equal diameter. In all other cases, an error of the magnitude of u²/2 will result, unless an explicit junction or fitting model is used. Contrary to the case of momentum balance, however, if the definition is changed to total enthalpy, then the balance is always correct for all kind of connections, without the need of an explicit junction model. This makes the use of total enthalpy attractive.

As to how we write component equations internally, considering the kinetic term in energy balances will always locally introduce a nonlinear coupling between momentum and energy balance equations, which will make equations more difficult to solve in cases of flow reversal (the usual problem), so these terms should be optionally included only when really needed.

In case of a chain of series-connected adiabatic flow components, if kinetic energy has to be considered, we have to scenarios.

1. If we define h_outflow as the total enthalpy, then this will be propagated unchanged as a stream variable across the chain, but the coupling will be introduced by the component accounting for kinetic effects, which will need to compute a thermodynamic state, and therefore to subtract u²/2 to the enthalpy.

2. If we keep h_outflow as the specific enthalpy, then the coupling will be introduced by those components which account for the kinetic effects, regardless whether energy form I or II is used.

We should check whether the former is easier or harder to solve than the latter, but I suspect there is not much difference.

As a final comment, using energy form II for components with changing cross section and/or velocity without approximation is not possible in general, as it requires to consider mean values of both, which cannot be determined exactly in general. Energy form I can be integrated exactly, but it requires computing speeds at the inlet and outlet.

[modelica-trac-importer]

Comment by otter on 24 Jan 2009 14:56 UTC
Here is one more piece of information:

If the energy form II is used, then the kinetic energy is removed from the energy balance equation (the balance equation contains only the thermodynamic effects). This means that the balance equation to be generated by connect statements is

sum(m_flow_j*h_outflow_j) = 0

i.e., this balance equation is correct in all cases (whether or not kinetic energy effects are treated or are neglected). So there is the same advantage as with using the total enthalpy in the connector.

If v-effects are neglected there is probably not much difference between energy balance I and II. If v-effects are not neglected, the essential difference is that for energy balance I, partial derivatives of v^2/2 with respect to time and with respect to position are present. For energy balance II no such derivatives are present, only the product of velocity with other terms (as also in energy balance I) and this can easily be transformed to mass flow rate. So the velocity in energy balance II is not explicitly appearing in this equation (only indirectly via the mass flow rate).

For the total enthalpy concept this is different: In order to compute media properties, one has to first subtract the v^2/2 term from the total enthalpy. This also means that one has to compute the velocity at every node where a medium evaluation is needed, which means that one needs to know the mass flow rate, the density and the area at this point. This is not nice. Probably, this only works reasonable for mean values in straight pipes (due to the area that is needed).

The disadvantage of the Energy Balance II form is that the additional terms are basically "v*A*der(p,x) + v*F_r" for a straight pipe. If there is no straight pipe one has to integrate the friction force F_r along the pipe and therefore the area along the pipe is needed as well.

[modelica-trac-importer]

Comment by eric.thomas on 26 Jan 2009 09:12 UTC
Comment about taking into account kinetic energy (fluid mean velocity) into Modelica_Fluid :
"> For about two months, I try to to develop ECS model from

Modelica_Fluid ... and will be interested further to model shock waves ....
I don't know what is the opinion of Michael Sielemann, who also
developp a ECS lib, but I consider that Modelica_Fluid is difficult to
use for such modeling (even if it has very good properties to model
many other fluid domains.) In ECS, we always have to distinguish
static and total properties.
Sometimes it would be interesting to have one of them (in the
connector), and sometimes the other ones.
I don't say that Modelica_Fluid is not usable for ECS, but to use it
model developpers must make several important assumptions, especially
on the signification of the enthalpy in the connectors, depending of
needs in the models.

For example, to switch from a definition the another one and obtain
suitable properties, I created the following model

replaceable model ECSDyn0
"ECS Dyn Base properties (total properties : p, T, m_flow => Ps, Ts,
Mach) of a medium"
import SI = Modelica.SIunits;
import CF = DasECSlib.Utilities.CommonFunctions;

InputAbsolutePressure p "Total absolute pressure of medium";
InputTemperature T "Total enthalpy of medium";
InputVelocity V "Velocity of medium";
SI.Pressure ps(start=1e5) "Static pressure of medium";
SI.Pressure pss(start=1e5) "Static sound pressure of medium";
SI.Temperature Ts(start=300) "Static temperature of medium";
SI.Density ds "Static density of medium";
Real Mach "Mach number";

// Local connector definition, used for equation balancing check
connector InputAbsolutePressure = input Modelica.SIunits.AbsolutePressure
"Total pressure as input signal connector";
connector InputTemperature = input Modelica.SIunits.Temperature
"Total specific enthalpy as input signal connector";
connector InputVelocity = input Modelica.SIunits.Velocity
"Velocity as input signal connector";

protected
constant Real r = 287;
constant Real gamma = 1.405;
parameter SI.SpecificHeatCapacityAtConstantPressure cp =
r*gamma/(gamma-1);
parameter Real kp = gamma/(gamma-1); //3.5

equation

//Hypothesis : Perfect gas (GP) ou semi-perfect (SP)
p = ps*(1+V^2/(2*cp*Ts))kp; //GP
p = pss*((gamma+1)/2)^kp; //GP
T = Ts*(1+V^2/(2*cp*Ts)); //GP
ds = ps/(r*Ts); //GP and SP
Mach = V/sqrt(gamma*r*Ts); //GP and SP

//Source : [R01] : "Thermodynamique et Energétique, Tome 1 De
l'énergie à l'exergie",
//PPUR, Lucien Borel-Daniel Favrat => p 151 et 161

end ECSDyn0;

Is'nt it complex, and not really rigourus ? Therefore, if these
properties (total and static) could be available more easily in
Modelica_Fluid, I would be very interested.

Best regards,

Eric Thomas
DA"

In addition, it would be intersesting that XRG which make FluidDissipation lib give their opinion.
Practices in DA:

• When we use pressure-drops handbooks, like I.E Idel'cik, we use total pressure and temperature, which can be reduced to static ones at low Mach number (<<0.3)

-About tests of compressible fluids in ECS systems:

• It is quite impossible to measure a static temperature in a fluid network
• Most of the time, we can measure total and static pressure (but often when only one can be measured, we prefer measuring total pressure)

Best regards,

Erid Thomas
DA

[modelica-trac-importer]

Comment by fcasella on 28 Jan 2009 15:13 UTC
A compromise has been reached and documented in version 1.0 (see #53).

For version 2.0 it might be good to reconsider lumped models (e.g. nozzles) where kinetic energy plays a significant role.

[modelica-trac-importer]

Modified by fcasella on 19 Apr 2009 19:04 UTC

[modelica-trac-importer]

Comment by msielemann on 23 Mar 2010 10:50 UTC
moved from https://trac.modelica.org/Modelica_Fluid/ticket/70

[modelica-trac-importer]

Comment by dietmarw on 27 Jan 2011 12:43 UTC
Milestone Modelica_Fluid 1.1 deleted

[modelica-trac-importer]

Modified by ahaumer on 6 Mar 2012 16:30 UTC

[casella]

Sorry, no way I can handle this in time for MSL 4.0.0.

[dietmarw]

I didn't schedule it for MSL 4.0.0 but just assigned it to the LOs so they don't forget about it like they obviously have done for the past 11 years 😏