We Gunnslingers tend to speak in our own language. This is our dictionary!

See Admittance. This is the overall tendency of a node’s potential to change in response to the effects of its incident links.

See Admittance Matrix. The matrix [A] in the GUNNS system of equations: [A] {p} = {w}. It mainly describes the connectivity of the system nodes to each other via conductive links (in the off-diagonal terms), and also partially implements node capacitance (on the diagonals). It is a symmetrical positive-definite matrix of size NxN, N being the number of normal nodes in the network. It is set by the links, who calculate their contributions to the system of equations in the admittance matrix and source vector.

A term that comes from the Aspect Design Architecture, which divides the simulation of hardware components into separate code objects for each of their various disciplines, or aspects. Each aspect can then more easily interface with other hardware component’s similar aspects in a unified solution. The 3 aspects currently solved by GUNNS are Fluid, Electrical, Thermal. A 4th aspect, Signal, is sometimes solved with ER’s Signal Solver. A liquid pump, for example, can be divided up into all 4 aspects. The Fluid aspect governs the fluid mechanics of the pump – the pressure rise that it creates as it spins, and how much flow it creates, etc. The Electrical aspect governs its electrical properties – how much current and power load it draws from the electrical supply, etc. The thermal aspect governs the temperature of the pump. The Signal aspect governs data flow to and from the pump’s control circuitry and models its control logic.

There are two types of GUNNS networks, nodes, and links: basic and fluid. Basic networks implement the system of equations in its most basic and generic form. Parameters in these objects are unit-less, and so can be applied to any system. Basic networks can be conceivably used to solve any system of the form: [A] {p} = {w}. Our electrical and thermal networks are basic networks.

See: Capacitance. This is one of the 4 main GUNNS effects, conveniently implemented by the GunnsBasicCapacitor and GunnsFluidCapacitor links in basic and fluid networks, respectively. Capacitance is the ability of a node to store quantity. In the GUNNS system of equations, it defines the amount of quantity to add to a node to raise its potential by a unit. These links give the attached node their capacitance. Capacitance has analogs in all 3 GUNNS aspects:

• In electrical networks, capacitance is electrical capacitance.
• In thermal networks, capacitance is thermal capacitance (generally mass * specific heat).
• In fluid networks, capacitance is proportional to volume. Specifically it is the fluid moles * compressibility. Liquid volumes tend to have very low capacitance because liquids have very low compressibility.

See: Network_Capacitance. This is a property of all nodes and extends the regular capacitance concept. When you add quantity to a node, some of that quantity inevitably gets spread out to the surrounding nodes in the network through conductive pathways. So although a node’s regular capacitance describes its own dQ/dP, it doesn’t know about the rest of the network. The Network Capacitance does — it is the equivalent dQ/dP of the whole network to quantity added at this node. It is a better predictor of what the resulting node potential will be when you add a given amount of quantity.

By default, nodes are non-capacitive, meaning they cannot store quantity and their potential is tied to nearby capacitive nodes or potential sources. Nodes are given capacitance by an attached capacitance effect link. In general, any node with a capacitor link on it is a capacitive node.

See: Conductance. This is one of the 4 main GUNNS effects, conveniently implemented by the GunnsBasicConductor and GunnsFluidConductor links in basic and fluid networks, respectively. Conductance is the ability of a link to transmit flux through it. It is the inverse of resistance. See the Flux definition for the equation that relates conductance to flux and delta-potential. It basically says that the higher the link conductance, the more flux goes through it for a given delta-potential. Most conductive links are implemented by connecting two nodes, such as a pipe, electrical wire, radiative path, etc. When conductance links connect a normal node to ground, they cause flux to exit the network. Link models that only contain one port are essentially conductors to ground.

In GUNNS, this is the same as Conductance. This can be a source of confusion because in the real-world, there is an important distinction between Conductance & Conductivity: Conductivity is usually an intrinsic property of the material, i.e. thermal conductivity of a material is in units of W/K/m. Conductance of an object combines the material’s conductivity and the object geometry, i.e. thermal conductance of a heat pipe of a certain length (units m) has units of W/K. Conductance is the more useful parameter for GUNNS because it relates flow directly to potential so that a GUNNS conductor link doesn’t have to know about the system geometry. However, when we wrote a lot of the GUNNS code, we were lax in the formal distinction between the Conductance & Conductivity terms, and we mistakenly label some terms conductivity when we really mean conductance.

This is an effect that can be modeled in non-linear networks. It should be thought of as a variant of the Conductance effect in GUNNS. A constant power link is simply a conductor that modulates its conductance to control a desired power dissipation through itself. Since power dissipation is a function not only of the link’s conductance but also the delta-potential across it, and power loads on a potential supply tend to affect the supplied potential, constant power loads form a closed feedback loop with power supplies. This requires multiple iterations of the network to converge on the values of potentials and conductivities that are in equilibrium with each other and producing the desired power. This is an example of how non-linear networks iterate within each major step to provide such a solution.

This usually refers to the runtime components of the GUNNS toolset in the gunns/core and gunns/aspects folders.

A passive mode of the solver. In Dummy Mode, the solver doesn’t solve for the network potentials. Instead, it merely calls the links to execute them and lets them calculate their own node potentials. Any connections between nodes are left purely to the links to resolve – there is effectively no network and no simultaneous system solution. This mode allows the same link classes to function in a normal network or standalone, without changing their code. This mode was originally developed to satisfy TS21’s need for networks to collect various thermal aspects that needed to be executed, but didn’t necessarily need to interact with their environment, i.e. small heat load-producing hardware that are always in thermal equilibrium with the air inside a vehicle cabin, etc. This is commonly used to model the thermal aspect of segments in heat exchangers.

GUNNS has 4 flow system effects that are analogous between all types of networks: conductance, capacitance, potential source, and flux source. These are implemented as base classes in gunns/core. Most GUNNS link models derive from these base classes.

These are special links that are designed to interface networks together. Each pair of these links produces a direct potential-flux interface between two networks. A supply link in the supply network supplies potential to the demand link in the demand network, and the demand link calculates a flux between the two networks in response to the supplied potential. Because these networks flow quantity between them, this type of interface is only used between two networks of the same aspect.

There are two types of GUNNS networks, nodes, and links: basic and fluid. Fluid networks extend the functionality of basic networks to solve fluid mechanics problems. In addition to the generic analogs contained in the base class: potential (pressure) and flux (molar flow rate), fluid networks simulate many other properties of fluids and also perform mass transport. Flux is related to mass flow rate via the molecular weight of the fluids. Fluid properties and state equations are implemented in the PolyFluid class, which is independent of GUNNS. GUNNS can simulate mixtures of ideal gases, and can also simulate non-ideal single-species gases and single-species liquids, as long as their state equations are implemented in PolyFluid.

A generic concept across all 3 GUNNS aspects, flux is the movement of quantity between nodes in the network. In GUNNS, flux F is related to link conductance G and delta-potential dP by: F = G * dP. This is the central governing equation at the heart of GUNNS. Note the similarity in form to the system of equations that is solved for in GUNNS: [A] {p} = {w}. Flux has analogs in all types of networks:

• In electrical networks, flux is electrical current.
• In thermal networks, flux is heat flux.
• In fluid networks, flux is molar flow rate (not mass flow rate!)

Similarly to the conductance/conductivity terms, our distinction between flux & flow is a bit lax. Typically in fluid & heat transport, flux is formally defined as flow per unit area. However in GUNNS when we say “flux” we really mean flow. We chose the word “flux” as a generic term to represent the analogous concepts of electrical current, heat flow, and fluid flow.

Everything outside of the network is represented by a special node called the ground, or vacuum, node. It creates a zero potential boundary condition in the network.

• In electrical networks, this represents a perfect electrical ground (hence the name).
• In thermal networks, this represents a perfect heat sink and/or deep space.
• In fluid networks, this represents perfect vacuum.

General-Use Nodal Network Solver

This is our new network design GUI. It is custom Draw.io shape libraries that allow users to graphically design and configure fluid, thermal and electrical networks, and a set of Python scripts that can auto-generate network code that instantiates generic GUNNS core C++ classes for building into simulations.

Routines for Optimizing Sparse Systems (ROSES) is our name for solving the network linear algebra on a GPU. This can be much faster than solving on the CPU for large networks. Currently we only support running on NVIDIA GPU’s using their CUDA library.

This was our old network design GUI, and it has been replaced by GunnsDraw. It was a plug-in to Microsoft Visio. We replaced it mainly for platform independence. GunnShow is no longer maintained or released.

This is an old component of the GUNNS toolset, though it was never completed and is no longer maintained or released. The idea was to be the run-time network visibility GUI, which displays a network’s runtime sim data onto the same GunnShow or GunnsDraw image used to design the network. We may resurrect this someday.

What we call “islands” are also called “partitions” or “blocks” in linear algebra. These are groups of rows (nodes) in the [A] matrix that are independent of the rest of the matrix. Decomposing [A] separately for each island can greatly speed up the network solution. The solver has an island mode setting that determines whether to use islands. The settings currently are:

• OFF: Islands are not found or used in the solver. Certain links and spotters that depend on islands being found by the solver do not work in this mode.
• FIND: Islands are determined & output to nodes but not used in solver.
• SOLVE: Islands are decomposed separately by building new island admittance matrices. This solves faster than SOLVE_2 so it is the preferred mode.
• SOLVE_2: Islands are decomposed separately within the main admittance matrix.

An object that creates a relationship between one or more nodes. All ‘models’ in GUNNS are links! All links are either basic or fluid links and can only run in that type of network. All basic links must derive from the ultimate base class GunnsBasicLink. All fluid links must derive from GunnsFluidLink (which itself extends GunnsBasicLink). Furthermore, gunns/core contains a second level of link base classes called the effect links. These classes, such as GunnsBasicConductor, GunnsFluidCapacitor, etc, provide a handy and easy way to model an effect in the network. Most GUNNS models derive from these effect classes, and their use in new models is encouraged.

The GUNNS solver is called exactly once by the network for each call to the network by the Trick scheduled job. This is called a Major Step in the solver. For linear networks, each Major Step results in one solution & propagation of the network’s state.

Any class that contains or extends a GUNNS network.

For non-linear networks, the solver does multiple solutions & propagations of the network’s state in a loop, to converge to an iterated solution each time it is called by the network. Each of these internal loop cycles is called a Minor Step.

A class containing a group of nodes and links that are solved in a single system of equations. A network always contains:

• One orchestrator (the solver),
• At least two nodes (at least one normal node plus the ground node),
• Zero or more links (although a network with no links won’t accomplish much).

Networks may also contain spotters and other aspect-specific objects like fluid states.

Networks are usually auto-generated from a user’s drawing by GunnsDraw, but they can also be written by hand. Some are generic with each instance configured by input files.

A location in the network where the potential is solved for. Nodes are connected to each other by links.

• There are two classifications of nodes relevant to the solver:
  • A normal node, which corresponds to a row in the system of equations and whose potential is solved for by the solver. The number of normal nodes in the network affect how much CPU power it takes to solve the network. The CPU demand of a network increases with roughly the 3rd power of the number of nodes. Therefore we try to limit the number of nodes in a network whenever possible.
  • A ground/vacuum node. It doesn’t exist in the system of equations, but does exist as a node object that links can connect to. It always has zero potential, and in fluid networks, most fluid properties are zero.
• The are two types of node objects:
  • The GunnsBasicNode class is the type of node used in basic networks.
  • The GunnsFluidNode class is the type of node used in fluid networks. This extends GunnsBasicNode. Fluid nodes contain a PolyFluid class object that represents the fluid properties inside the node, as well as other parameters unique to fluid networks. Links incident on fluid nodes can govern some of these properties. For instance, a GunnsFluidCapacitor link controls the volume of the node and is responsible for initializing the fluid properties inside the node.

A non-linear network is one that contains one or more non-linear link objects. In non-linear networks, there is a closed feedback loop between the link’s contributions to the system of equations and the potential solution that needs to be iterated to a converged solution inside of each major step of the network. Each such iteration, called a minor step, basically repeats the process of a normal network step, and iterations continue until the network is converged or the maximum number of allowed minor steps has been reached. The network is converged when each successive minor step produces changes in all network potentials below a pre-defined tolerance.

The mode most often used in GUNNS and its primary design purpose. In Normal Mode, GUNNS solves for the network potentials using the contributions to the system of equations from the network links.

A term related to Aspect Design Architecture, an orchestrator is the code object that operates on an aspect as a whole. In GUNNS terms, the Orchestrator can be thought of as either the Solver or the network Manager – the distinction is vague.

This is a term to describe the connection of a link to a node. Links have a number of ports equal to the number of nodes they are designed to connect to. The parameters in the link base classes that refer to the nodes are often indexed by “port” number. For instance, say a pipe needs to connect nodes A and B. The pipe link’s ports correspond to the ends of the pipe, so port 0 can connect to node A and port 1 would then connect to node B, etc.

• The effect link classes in gunns/core are always 2 ports and are written such that flux is defined as being positive in direction from port 0 to port 1.
• We often say “node mapping” when describing the assignment of ports to nodes. The base link classes have methods to map a port to a node – this is done during link initialization, and can also be changed during run-time. This node mapping logic also contains validity checks that link models can override based on their particular node mapping limitations.

Potential is the generic parameter that is solved by the network solver, and it has analogs in all 3 GUNNS aspects:

• In electrical networks, potential is Voltage. The default Trick units is (v). Electrical potential values are always referenced to a zero Ground value, and can have negative values.
• In thermal networks, potential is Temperature. The default Trick units is (K).
• In fluid networks, potential is Pressure. The default Trick units is (kPa).

Note than in all 3 aspects, the GUNNS solver can solve for negative potential in a node. This only physically makes sense in the electrical aspect. Negative pressures and temperatures are obviously invalid and are only caused by a badly set up network or link.

See: Potential_Source. This is one of the 4 main GUNNS effects, and is conveniently implemented in the GunnsBasicPotential and GunnsFluidPotential links for basic and fluid networks, respectively. The potential source effect creates a potential rise across the link from port 0 to port 1. This has two primary uses in GUNNS networks:

• To simulate hardware that can create delta-potential and flux, such as fans & pumps in fluid networks, and batteries, solar panels, and other voltage sources in electrical networks. This application usually connects the Potential Source link between two normal nodes.
• To create a boundary condition at a particular node in a network, essentially forcing the node potential to a controlled value. This is used to represent the potential of a supply network in the demand network (see External Demand above). This application of Potential Source usually involves linking between the desired control node and ground.

The set of node potentials that GUNNS solves for every step. It is the {p} vector in the system of equations: [A] {p} = {w}. Each potential value corresponds to a normal node in the network. Normally, only the solver sets the potential vector, and links do not set it directly – rather, links cause the potential to change by modifying the admittance matrix [A] and source vector {w} and the solver solving for the resulting potentials.

Power is a generic parameter that is analogous between the 3 GUNNS aspects. Power is generally flux times potential and has units of Watts:

• In electrical networks, it is electrical power (P = IV).
• In thermal networks, it is most often useful in describing radiated heat flux. Note the thermal aspect is unique in that power is equal to flux.
• In fluid networks, it is fluid power (often called pneumatic for gases and hydraulic for liquids).

The integral of flux over time. Quantity only has meaning in capacitive nodes (e.g. a tank with no volume can store no fluid). Quantity has analogs in all 3 GUNNS aspects:

• In electrical networks, quantity is electrical charge.
• In thermal networks, quantity is heat.
• In fluid networks, quantity is fluid moles (not mass!).

This was an early concept (no longer supported) by which manual changes to an exported GunnShow network class could be imported back into the GunnShow Visio drawing. This was useful for updating the drawing with new values for shape data that had been changed by hand during debugging & tuning, etc. We may resurrect this someday to work with GunnsDraw.

The Trick Thread-Safe Sim Bus. This is a model-to-model data flow system that was developed in concurrence with GUNNS during the TS-21 project. It is not officially a part of GUNNS or included with GUNNS. However, GUNNS was designed and optimized for Sim Bus as the main method to transfer data between networks, aspects and other models.

A mode of the solver in which the network potentials are provided by an external source (such as another network or even an external simulator). In this mode, the solver simply takes the externally supplied potentials and stuffs them into the network potentials for output to the links. This allows the network to essentially become a sub-network of the “master” network.

Implemented by the Gunns class, this is the code that contains the algorithms to execute the network links and nodes, and solve for the network potentials. The solver is called once by the network manager during each update cycle of its Trick run job. The solver performs these basic steps:

1. Execute the network links to get their contributions to the system of equations.
2. Use the Cholesky Decomposition numerical method to invert the Admittance Matrix to compute the new network potentials for the step.
3. Output the potential solution to the links and execute them again so they can process their flows in response to the potential solution.
4. Execute the network nodes to accumulate transported quantities from the network links.

The GUNNS solver has 3 operating modes that it can switch between during run-time, based on the particular needs of the network in the simulation environment. See the description of these modes elsewhere in this glossary:

• Normal Mode
• Dummy Mode
• Slave Mode

See: Source. This is one of the 4 main GUNNS effects, and is conventiently implemented by the GunnsBasicSource and GunnsFluidSource links for basic and fluid networks, respectively. Also called Flux Source or Flow Source, this effect forces flux through a link and creates a flux boundary condition between two nodes in a network. It is usually used to add an external flux demand at a particular location in the network, causing quantity to enter or leave the network.

This is the vector {w} in the GUNNS system of equations: [A] {p} = {w}. It is set by the links and is involved in most of the various effects in GUNNS. In fact, conductance is the only effect that doesn’t use the source vector at all.

A spotter is a special type of object that resides in the network alongside the solver, links & nodes. Its function is to interface with any of those objects as needed to process inputs & outputs to them before and after each solver step. It is intended as a convenient way for users to implement custom class objects and functionality in their networks without the overhead of creating or modifying a link. A spotter is like a link except it is called by the network instead of the solver, and it doesn’t directly contribute to the system of equations. Examples of spotters and their uses are:

• GunnsFluidIslandAnalyzer: This is an example of a spotter that interfaces with nodes. It provides analysis of the attached island for output to various consumers — things like how many and which nodes are in the island, which nodes have the min/max values of fluid properties like pressure, temperature, etc.
• GunnsMinorStepLogDumper: This is an example of a spotter that interfaces with the solver. This provides a file dump of the solver’s minor step performance metrics, useful for analyzing & debugging the performance of non-linear networks.
• SimpleQdIntAdapter (in the TS-21 user domain): This is an example of a spotter that interfaces with links. It provides an interface to command a GunnsFluidSimpleQd link via integer value, by converting the supplied integer command to the enumeration type that the GUNNS link needs. Such “adapter” functions are common uses of spotters.

A super-network is a special network that contains pointers to other normal networks (called sub-networks) and solves them as one simultaneous system with its own solver and set of nodes. This provides flexibility in arranging and connecting models.

TS21 was the parent NASA project under which GUNNS was first developed. It was a Trick-based simulation of the International Space Station.

See Ground above.

We have names for different personal associations with GUNNS:

One who develops gunns/core.

Anyone who uses GUNNS.

One who is afraid of/opposed to GUNNS. Blasphemer, heretic. Outcast.

One who might market or deploy the GUNNS tool.

Developers who are new to/likely to hurt themselves with GUNNS.

One who knows a lot about/can do a lot of damage with GUNNS.