Whereas Capacitance describes the change in a node’s potential to quantity added to the node in isolation, Network Capacitance describes the change in a node’s potential to quantity added to the network at that node’s location.

The capacitance on a node describes the amount of quantity added to the node to cause a unit increase in its potential, assuming that all of the added quantity remains in the node (or more correctly in the capacitor and in between the nodes it connects). However, nodes are usually connected to other nodes in the network through other conductive links. When quantity is forced into a node, the network solution includes the node’s capacitance as well as the effect that some of the quantity will go to other nodes through those conductive paths instead. Therefore, the link’s capacitance at a node is not enough to predict what the resulting node potential will be when flow is added.

There are many types of links that force flow directly into or out of a node using the Source effect – these are generally called “source” links. Examples include GunnsBasicSource, GunnsFluidExternalSupply, and the various positive displacement pump links. The Source effect forces quantity into or out of nodes without regard to whether the network has any capacity to receive or supply that flow. An obvious example is trying to force a non-zero flow into a non-capacitive node that has no other flow paths out of it. Since the node has zero capacitance (it represents an infinitely small point), the resulting potential of cramming non-zero quantity into zero space is infinite potential — in GUNNS this effectively “blows up” the network. Cases like this are very undesirable, so one has to be careful when using Source links to avoid instability.

One way to avoid the above instability is for the source link, or the provider of the source flow rate, to take the network’s capacity to receive or supply flow into account when calculating the flow rate. The Network Capacitance can be used for this. In the above example, the source link would check the node’s network capacitance, and finding it zero, would zero out its flow rate into the node.

This link can be configured to send the network capacitance of the node it attaches to (the supply node in the supply network) over to its paired GunnsFluidExternalDemand link, for the latter to use in its demand stability filter. The demand link takes the supply network’s capacitance into consideration by using it to modulate its internal conductivity — as the supply network capacitance drops, the demand link’s conductivity shrinks, causing a lower demand flow rate from the demand network. See the GunnsDraw link help pages for these links for more information.

To enable the solver to calculate a node’s network capacitance, the user (usually a link or spotter) must call the node’s setNetworkCapacitanceRequest(const double flux = 1.0) method. The flux argument is optional. It will default to 1 but you can use different values if you want (see below). Calling this method with any value > DBL_EPSILON will cause the solver to calculate the node’s network capacitance and store it in the node. The solver does this during each network solution, so the new network capacitance value is available in the node during calls to the links’ post-solution methods like computeFlows, confirmSolutionAcceptable, etc.

If no-one calls the node’s setNetworkCapacitanceRequest method prior to each solver solution, the node’s stored network capacitance value is zeroed by the solver. This happens for each major & minor step solution, so if a user wants the network capacitance in between minor steps, they must keep calling setNetworkCapacitanceRequest each minor step.

The calculated network capacitance is stored in the node’s mNetworkCapacitance term. It can be accessed by links & spotters via the node’s getNetworkCapacitance getter method.

Network Capacitance C _n has the same units as regular capacitance, i.e. C _n = dQ/dp, except it applies to all of the network exposed to the node through conductive paths. Since the other exposed nodes cannot have negative capacitance, the network capacitance at a node is always equal to or larger than the node’s capacitance:

C _n >= C

The GUNNS solver calculates the network capacitance of nodes that request it. It is a moderately CPU-intensive calculation, so we only calculate the network capacitance for nodes that actively request it each pass. The calculation uses the same decomposed [A] matrix that is used in the normal network solution. In GUNNS, we use the Cholesky LDU decomposition as our standard numerical method for solving the system. The initial admittance matrix [A], built from the link’s contributions, is decomposed into the product of lower triangular [L], diagonal [D], and upper triangular [U] matrices:

A = LDU

Once LDU is calculated, we call this the “decomposed admittance matrix”. It is valid for any source vector {w}, meaning we can reuse it for any changes to w as long as the original A doesn’t change. The new network solution for the potential vector {ps} is solved from LDU and w via a process called “Cholesky Solve” (as opposed to “Choleksy Decompose”). This Solve process is computationally much cheaper than the Decompose process, so we can afford to do it multiple times in a network step.

To find the network capacitance at each desired node i, we perturb the node’s term in the source vector {w} by a value dQ, recalculate a perturbed potential vector {pp} solution for the perturbed source vector, and compare the perturbed node potential and the original network solution node potential {ps}:

dp _i = {pp} _i – {ps} _i

The node’s network capacitance is then:

C _n = dQ/dp _i

We use a different perturbed {w} for each node i, where the perturbed {w} is identical to the normal network’s {w} with only the node _i_’s term increased by dQ. This causes the resulting perturbed solution {pp} to only include the difference that adding dQ to only node i makes, for each desired node i at a time.

We can use any value for dQ we want. The default value is 1 (in whatever units represent flow in the aspect), but we allow users to supply the value of dQ they’d like the solver to use, just in case it affects the resulting C _n (although as we’d expect, in testing different magnitudes of dQ, the value doesn’t seem to have any effect).

This results in unique C _n values for each node assuming the dQ is only added to the network at that node. This is the best predictor we can get of what the node’s potential will do in response to an added source flow on the next pass.