As mass and energy flow around in a GUNNS fluid network, mass and energy are generally conserved. That is, any mass or energy added tends to stay in the network as it gets transported around until it is deliberately removed. GUNNS tries very hard to honor this as the conservation laws are an important part of physics and our users tend to care about them. Often a link will deliberately add or remove fluid mass and/or energy according to some real-world process, and this is desired. Common cases are:

• mass flows between networks,
• leaks out into space,
• fluid mass changed into a solid via a chemical reaction and trapped in a reactor, or vice-versa,
• user edits to change the pressure or temperature in a tank,
• heat (energy) transfer between the fluid and a pipe or container wall
• there is a more complete list here.

Sometimes, a network can lose or gain fluid mass and/or energy in an undesired way, when the real physical system would conserve it. In GUNNS release 19, the fluid transport has been upgraded to eliminate most of these errors. This page describes the known causes of these errors in GUNNS and how to mitigate them, for both release 19 and prior releases that don’t include the upgrade.

All GUNNS fluid transport happens through links. For instance, a conductor connecting Nodes 1 and 2 might flow some fluid from Node 1 to Node 2, etc. It is the link that calculates the flow rate (from the network solver's pressure solution), and it is the link that transports the corresponding mass of flow between the nodes. The fluid is transported by removing a mass of fluid from the supplying node and adding an equal mass to the receiving node. Unless there is some physical process being simulated or a user edit (override) that deliberately changes the quantity, links always add an equal mass and energy to the receiving node as was removed from the supplying node.

Furthermore, when transporting mixtures of fluids (such as air), unless there is some physical process being simulated that changes the fluid mixture (such as a chemical reaction or absorption, etc.), then each fluid constituent’s (N2, O2, etc) mass is also conserved, i.e. each constituent is added to the receiving node in the same amount as is removed from the supplying node. This means that all of the flow from Node 1 to 2 is at Node 1’s mixture. GUNNS assumes (always prior to release 19, only sometimes in 19) that the supplying node’s mixture is constant over the integration time-step, so that the entire flow over the time-step is at that constant mixture. This is a big simplification because in reality, if there is more flow entering the supplying node from somewhere else (say Node 0) with a different mixture than what Node 1 originally had, then Node 1’s mixture and the mixture of its flow to Node 2 should really be changing over the time-step and isn’t really constant. This simplification saves us a lot of code complexity and CPU time because to integrate flows with changing mixture we’d need a separate iteration loop just for fluid transport. Release 19 added just such an iteration loop, which is how it avoids most of these conservation errors.

During a single execution time step of the network, if more mass flows through a node than the amount of mass it had to start with, then the previous fluid mass in the node is completely replaced by the incoming fluid. This is called a mass overflow. Because GUNNS does all mass transport in one pass (prior to release 19), as opposed to an iterative loop (in release 19 discussed above), simplifications and assumptions are required to handle the overflow case, and these lead to non-conservation of mass and energy in various ways. Thus, prior to release 19, overflows are best avoided if you want to strictly conserve mass and energy. There is more discussion on how to spot and avoid overflows below.

Mass overflows don’t always cause conservation errors. When errors do occur, this sections describes what they are and how they occur.

Since in an overflow the previous node fluid contents are completely replaced by the incoming flow, the node just sets the new contents equal to the incoming flow properties at the new solution pressure. This can create or destroy mass because of the fluid state error in the pressure solution. In other words, whereas normally the solution pressure is considered incorrect and the node mass considered correct when they disagree, in the overflow case the node must assume that the solution pressure is correct and the actual mass is reset to match the solution pressure.

Flows exiting a node should have the node’s mixture until the exiting flow amount is more than what is actually present in the node. Ideally at that point, the remaining exiting flow would then take the mixture of the inflow, but GUNNS doesn’t do that. Instead, all of the exiting flow keeps the mixture of the initial node contents. This causes some error in the component fractions for fluid mixtures when this node and the source nodes have different mixtures.

To help visualize this, let’s say we have 3 nodes in a network (Nodes 0, 1, 2) that has ideal N2 and O2 in it. We’ll say that the initial masses of N2 and O2 in the nodes are:

Initial Masses (kg):

Gas Type	Node 0	Node 1	Node 2	Total
N2	1.6	0.7	0.0	2.3
O2	0.4	0.3	0.0	0.7
Total	2.0	1.0	0.0	3.0

Node 2 is starting empty.

Now, let’s flow 0.1 kg from Node 0 to Node 1, and from Node 1 to Node 2. Each receiving node recieves 0.1 kg from its supplying node at the supplying node’s mixture. The resulting masses are:

Masses After Step 1 (kg):

Gas Type	Node 0	Node 1	Node 2	Total
N2	1.52	0.71	0.07	2.3
O2	0.38	0.29	0.03	0.7
Total	1.9	1.0	0.1	3.0

Looks good so far: we have the same total masses of each constituent, so we’ve conserved mass. Now let’s increase the flow to 1.1 kg. Note that this is more than Node 1 has in it to begin with. It will flow 1.1 kg of mass to Node 2 at its mixture, even though it should only have 1.0 kg at that mixture to give. The resulting masses are:

Masses After Step 2 (kg):

Gas Type	Node 0	Node 1	Node 2	Total
N2	0.64	0.8	0.851	2.291
O2	0.16	0.2	0.349	0.709
Total	0.8	1.0	1.2	3.0

The total node masses are correct, and the total system mass of 3.0 kg has been conserved, but we have destroyed 0.009 kg of N2 and added the same mass of O2! So we conserved total mass, but didn’t conserve the masses of the constituents. This is the problem, and it happened because we flowed more mass through Node 1 than it had in it. This is what the overflow condition means.

A similar problem occurs with the energy transported in the fluid. GUNNS models the specific enthalpy of the fluid. Specific enthalpy is a measure of energy content in a mass of fluid and has units (J/kg). When energy is added to or removed from the fluid via physical processes that we are modeling, such as wall convection, we want that energy to be conserved as we transport it around the network. This is particularly important for coolant loops, whose main purpose is to transport energy (heat) from one place to another. Even though our model of enthalpy is greatly simplified (see limitations 5 & 6), it is still good enough to allow for the conservation of energy in our fluid.

Similar to the above mass flow example, we’ll look at the energy content of a system. Again, we have 3 nodes (Node 0, 1, 2). This time we only have liquid water as a single constituent. For clarity, we’ll simplify the specific heat Cp to be a constant 1 kJ/kg/K, and specific enthalpy h to be Cp * T = 1 (kJ/kg/K) * T = T (kJ/kg).

Initial State:

Property	Node 0	Node 1	Node 2	Total
mass (kg)	2.0	1.0	0.0	3.0
specific enthalpy (kJ/kg)	300.0	290.0	290.0	n/a
temperature (K)	300.0	290.0	290.0	n/a
total energy (kJ)	600.0	290.0	0.0	890.0

Now let’s flow a small amount of mass (0.1 kg) from Node 0 to Node 1 and from Node 1 to Node 2, avoiding a mass overflow. (0.1 kg) * (300 kJ/kg) = 30 kJ should be transported from Node 0 to Node 1, and (0.1 kg) * (290 kJ/kg) = 29 kJ should be transported from Node 1 to Node 2:

State after Step 1:

Property	Node 0	Node 1	Node 2	Total
mass (kg)	1.9	1.0	0.1	3.0
specific enthalpy (kJ/kg)	300.0	291.0	290.0	n/a
temperature (K)	300.0	291.0	290.0	n/a
total energy (kJ)	570.0	291.0	29.0	890.0

Looks good so far: total energy is the same. 30 kJ of energy was lost by Node 0 and gained by Node 1, and 29 kJ was lost by Node 1 and gained by Node 2.

Now let’s flow 1.1 kg to cause an overflow and see what it does to the energy. (1.1 kg) * (300 kJ/kg) = 330 kJ of energy should be transported from Node 0 to Node 1, and (1.1 kg) * (291 kJ/kg) = 320.1 kJ of energy should be transported from Node 1 to Node 2. However Node 1 overflows, so its previous mass has been completely replaced by mass from the incoming flow and it takes the properties of the incoming flow (Node 0):

State after Step 2:

Property	Node 0	Node 1	Node 2	Total
mass (kg)	0.8	1.0	1.2	3.0
specific enthalpy (kJ/kg)	300.0	300.0	290.91667	n/a
temperature (K)	300.0	300.0	290.91667	n/a
total energy (kJ)	240.0	300.0	349.1	889.1

The total energy dropped: we lost 0.9 kJ of energy because some of the mass flow entering Node 2 should have been coming directly from Node 0 (passing right through Node 1 because of the overflow) and thus should have been hotter.

These differ between releases 19 and prior.

Because release 19 avoids most of the mass overflow errors, it is no longer worth it to track the accumulated errors. All of the node variables for counting the overflow occurrences and tracking accumulated mass & energy errors have been removed. Instead, GUNNS will output warnings to the Health & Status log when errors occur:

This warning indicates the flow orchestrator couldn’t find a good order to update the links and nodes to avoid errors. This is usually due to a closed loop of all overflowing nodes, or a link that has both flows to and from an overflowing node:

WARN | GUNNS | +000 00:00:02 | 2019-09-05T15:00:12Z | /…/gunns/core/GunnsFluidFlowOrchestrator.cpp:189 checkAllComplete() | network.netSolver.mFlowOrchestrator early overflow transport in link network.vlv3, conservation errors may result.

This warning will usually be caused by a link that didn’t flow as much mass into a node as it told the solver to solve for and would leave one or more constituents with a negative mass value. The node replaces these negative mass values with zero, effectively creating mass & energy. This commonly happens with adsorber and reactor links:

WARN | GUNNS | +000 00:00:04 | 2019-09-05T15:00:12Z | /…/gunns/core/GunnsFluidNode.cpp:592 integrateFlows() | network.Node_1 invalid mixture due to zero node mass after inflow, conservation errors may result.

GUNNS tells you when you have a mass overflow condition. The fluid nodes have a variable mMassOverflows that counts the number of steps that an overflow has occurred in each node. You can easily list these counters for the entire network in Trick View by displaying the full range of the .netNodes[array].mMassOverflows array.

Note that these counters only increment for capacitive nodes. Non-capacitive nodes always overflow by definition (since they contain zero mass) so we don’t bother counting for them.

NOTE: New for release v14.3, we have re-organized and improved data collection for these errors. See Fluid_Conservation_Error_Data for more details.

This varies between release 19 and prior:

• Avoid closed loops of all overflowing nodes. Closed flow loop are common, such as coolant & air ventilation loops. Make sure at least one node is not overflowing. If all are overflowing, then pick a node that will be the non-overflowing node, and give it some volume taken from the other nodes, until its volume is large enough to avoid overflowing. This trick can fix an overflowing loop whilst keeping the same total loop volume.

Just because mass overflows are occurring doesn’t mean you have mass or energy loss/gain (see below), so they’re not always bad. But they’re usually bad and you should try to avoid them. The only case in which they don’t cause mass or energy loss/gain is in a constant-mixture and constant-temperature system.

To avoid mass overflows, don’t use non-capacitive nodes where you care about mass and energy conservation, and size the volume of capacitive nodes or the network’s time step so that they always contain more mass at any instant in time than your system will ever flow through them in one time step. See the discussion on Mass Overflows in GunnsFluidCapacitor.

To summarize, mass overflows occur when:

• The total mass flowed through a node during a network time step is greater than the mass that was in the node at the beginning of the time step. Or,
• The net flows of any constituent would have left the node with negative mass of that constituent.
• Since non-capacitive nodes have zero mass, mass overflows always occur in non-capacitive nodes.

Mass overflows can cause the following conservation errors:

• Total mass gets lost or created if there is fluid state error in the node’s pressure solution. This occurs when the temperature of the incoming flow is different than the outflow, or if there are changing mixtures of non ideal-gas fluids.
• In fluid mixtures, constituent masses get converted from one type to another whenever the node’s inflow has a different mixture than its outflow. Yes, we’re talking about alchemy here.
• Energy is lost or gained when the node’s inflow has a different enthalpy than its outflow.

Mass overflows can be found and avoided by:

• (prior to release 19 only) looking at the fluid node’s mMassOverflow counter to determine which nodes are overflowing,
• adding volume to the node (via a capacitor link) or reducing the network’s time step.
• In release 19, avoid closed loops of all overflowing nodes.