{{toc}}

This looks really bad but fear not, it’s not that serious. You’ve noticed a “feature” of Trick. The short answer is that Trick View is lying to you, and is grabbing an intermediate value out of the model before the model has finished updating it. Some GUNNS terms, such as the node’s mOutFluxRate, are zeroed at the beginning of each network step, and then calculated towards the end of the step. This is a necessary function in the GUNNS design. Trick’s Variable Server, due to the randomness of timing, sometimes picks off the model’s value between when it is zeroed and when it is set to its output value. Variable Server timing doesn’t sync with the models so it reads the value whenever it wants, and not when the model is ready for a term to be read.

Some terms are more susceptible than others, depending on how long they spend between being zeroed and set. Most terms in the nodes are especially vulnerable because they spend most of the network’s step time in the intermediate zero state.

The Thread-Safe Sim Bus is immune to this because it waits until the model step is finished before it reads the value. If you were to send these mOutFluxRate terms over simbus, you’d see continuous data values in the simbus stream and not these random zeroes. This is why we prefer simbus for model-model transfer — because it is thread-safe. This issue just affects Trick View and Trick Data Products.

Workarounds:

• When you can, plot terms from links instead of nodes — links are generally less susceptible to this. The reason is that we designed GUNNS with the links as the user’s main interface, and we didn’t intend the nodes to be an important output to the users. The strip charts below illustrate this: the link’s rpLioh.mFlowRate is identical in value to its inlet node’s netNodes ⁶.mOutFluxRate, and has zero drop-outs:

• On Strip Chart, you can somewhat alleviate the jarring dip lines by plotting points instead of lines, and just ignoring the zero points.