Fluid_Conservation_Error_Data - nasa/gunns GitHub Wiki

{{>toc}}

Fluid Conservation Error Data

Starting in Release v14.3 and ending with v19.0, GUNNS can detect and log how much mass and energy has been gained or lost in non-conservation errors caused by mass overflows. These errors can be logged at the node and network-wide levels:

Logging at the Node Level

Note this has been removed and no longer applies in release 19.

Every fluid node can calculate and accumulate the total mass, fluid constituent masses, and energy gain & loss due to mass overflows in that node. The node has an object called mConservationErrors that stores these accumulated values. Its attributes are:

  • mEnableFlag: this boolean turns on (when true) and off the data collection for this node. This overrides the network-wide spotter’s enable flag for this node (see below). When on, the node collects the total mass, constituent masses, and energy gain/loss. Note that the mass overflow counter increments whether this is enabled or not. This flag is always false by default. See below for how to initialize it.
  • mMassOverflows: this integer stores the total number of times an overflow has occurred at this node since the last reset. This increments whether data collection is enabled for this node or not.
  • mTotalMassGained (kg): this stores the total accumulated mass gain that the overflows have caused at this node since the last reset.
  • mTotalEnergyGained (J): this stores the total accumulated energy gain that the overflows have caused at this node since the last reset.
  • mConstituentMassGained (kg): this is an array by the fluid constituents in the network. It stores the total accumulated mass of each constituent type that the overflows have caused at this node since the last reset. The sum of all of these constituent errors should equal the total mass error. It is normal for noise to appear in these values due to arithmetic rounding when no real overflows are occurring.

The network’s Ground node does not collect any of this data.

Initializing the Node’s Enable Flag

By default, the mEnableFlag is false at network initialization, but there are several ways you can set it true:

  • Via Trick View (just like any other term)
  • The GunnsFluidNetworkConservationErrors spotter can initialize all node’s enable flags to true (see below).
  • The flag can be initialized via the Trick input file. The mConservationErrors object is protected in the fluid node class, but the node provides a public getter method called getConservationErrors(), which returns the address of the mConservationErrors object. So to set the enable flag from the input file, you’d do something like this:

network.netNodes[number].getConservationErrors().mEnableFlag = True

Resetting the Node’s Data

All of the accumulated values in the mConservationErrors can be reset to zero by calling the object’s reset() method. This can be done by the network spotter (see below), or via the Trick input file, as with the enable flag (see above).

Logging at the Network Level

Note this has been removed and no longer applies in release 19.

Non-conservation errors for the entire network can be found by using a GunnsFluidNetworkConservationErrors spotter. Add it to your network drawing in GunnShow just like any other spotter (see a guide on that here.) Since it’s network-wide, I like to name it “netConservationErrors” in my networks. Give it the netNodeList as its constructor argument.

It contains the same data as in the node’s mConservationErrors object (see the list above), except these values are the sum of all nodes in the network (except the Ground node). These are additional differences:

  • mEnableFlag: this can be initialized in the GunnShow shape data. It initializes all of the node’s enable flags to this value. Toggling this in run-time also toggles all of the nodes.
  • mResetFlag: this flag is normally false. Setting it true causes this spotter’s error data and all of the network node’s error data to be zeroed and re-accumulate from zero.

Special Considerations

Using the Island Analyzer

We can sometimes use Islands and a GunnsFluidIslandAnalyzer spotter to see conservation problems. The island analyzer spotter sums up the total quantities in a network island: total mass, total energy, etc. If you know that the island should be in a state where no mass or energy is being added or removed, then if the island analyzer’s totals are still changing, this indicates mass or energy non-conservation. Careful though, there are many ways to purposely add or remove mass or energy from a network, and you have to make sure none of them are occurring. This is an attempt to list of all the known ways to purposely add or remove mass or energy:

  • Any mass source flow into or out of the network. This includes:
    • External supply/demand links
    • Source flow links between Ground and a node
    • Potential source links between Ground and a node
    • Conductors between Ground and a node (leaks)
    • Any single- or multiple- constituent source flow links, such as reactors & adsorbers, human metabolics, condensing heat exchangers, etc
  • Any wall heat convection, which can be done in most conductor links, such as fans, valves, heat exchangers, pipes, etc
  • Any wall heat conduction, which can be done in most capacitor links, such as tanks & accumulators
  • Any use of the expansion scale factor. Expansion & compression does pressure-volume work by or on the fluid which changes its energy.
  • Any direct heat insertion, such as tank wall heat flux biases and fluid heater links
  • Any fluid user edits, such as pressure, temperature, mixture edits in tank links
  • Any volume edit, such as in capacitor & accumulator links
  • Any constituent or total mass change to a network also changes its energy, because fluid mass always has an associated energy content (enthalpy).

Conversely, we can sometimes use the island analyzer to verify the results of the node’s and GunnsFluidNetworkConservationErrors spotter’s error accumulation values. When placing the island analyzer on an island where mass overflows are occurring, and ensuring no on-purpose mass & energy changes are occurring anywhere in the island, and disabling node’s error collection outside of the island, then the accumulated errors should match the change in the island analyzer’s totals.

False Error Indications at Network Boundaries

TBD

⚠️ **GitHub.com Fallback** ⚠️