Elect_Aspect_Course_2_2_4 - nasa/gunns GitHub Wiki

Solution Checks: Confirm, Delay, Reject

In each minor step, after the solver solves for new potentials, it will send those potentials to the nodes and links, then ask every non-linear link whether it confirms, delays, or rejects the solution, via the links confirmSolutionAcceptable() function. Each link will return one of those 3 values.

The link’s response will usually depend on the voltages and currents across its ports. These may be truth values, or the output of associated sensors. The solver only provides the voltages, so any currents must be computed by the link, and any voltage and current sensors must be updated so their outputs can be checked. There is usually some sort of trip logic associated with each parameter that the link checks. For example, if a switch is checking its through-current, then it probably has the option to trip open and reject the solution if the current exceeds a trip limit.

Here is what the three response values mean:

Confirm

The link is happy with the voltages and currents. As far as it is concerned, it is ready to complete the major step, and is now waiting on the solver to call its transportFlows() and processOutputs() functions to complete the major step. Note however, that the solver might not be finished iterating, because the network might not be converged yet, or other links have delayed or rejected the solution. So even though a link returns the Confirm value, it must still be ready to continue getting more calls to its minorStep() and subsequent calls to confirm the next solution, and so on.

Delay

The link is not yet ready to confirm the solution, and has no reason to outright reject the solution yet. This is usually because it is waiting until its trip priority to do its checks. This allows the various links checks to be sorted in order of trip priority, which is key for isolating faults immediately upstream. When a link Delays, it is expecting more calls to this function with incrementing minor step counters, so that eventually its priority will arrive and it can finally confirm or reject the solution. A link should never delay indefinitely.

Reject

The link finds that there is something about this solution that is invalid. This will usually be a trip due to a voltage or current being out of limits, but can also be due to logical problems not associated with a trip. The link should take some action to change its state in response to the rejection. Switches will trip open, power converters will trip off, etc. An example of a non-trip rejection is the case of an dioded output (an actual diode, or the one-way output channel of a power converter) needing to switch between forward and reverse bias — the solution is invalid because current is going in the wrong direction, but there isn’t a trip associated with this change.

Responses of Solver to Results

TODO

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