Rationale

In many simulation models, the state of a model is reached over and over again, while the simulator generates sample data for a statistical evaluation. Let us call a part of a trace that starts at some state and returns to the same state a cycle. For many simulation models, we would expect that all actions show up in cycles, e.g., in a queueing network model with queues we would expect all arrival and departure actions to be present in a cycle, or in a dependability model, we would expect all failure and repair actions to be present in a cycle.
If an action is not present in a cycle but it is expected to be, then this may be do to an error in any of the actions that would contribute to the cycle and that now prevent the existence of a cycle.

Symptoms

Traviando identifies all cycles in a trace and extracts which actions occur in which cycle. It raises a warning if any particular action, like the one for this warning, is not seen in any cycle.
Cycles are usually not formed by single actions alone but sets of actions. So if an erroneous action specification prevents cycles, then there will be more actions that are not seen in any cycle and they all raise this warning.

Diagnosis

• Make sure that actions are not used to perform some kind of initialization such that their sole purpose is to occur once or a few times in the initial set up phase (warm up phase) for a simulation. For those actions, one would not expect to see them contribute to a repetitive, cyclic behavior.
• Check how often actions that generate this warning do occur and if there are actions that do not occur at all. If this is the case, check if the trace is simply to short to see the expected repetitive behavior and try a longer simulation run such that all actions occur sufficiently often.
• If all actions do occur and there are lots of those, identify subsets that should form a cycle and check their state transformation functions in the model and in the trace (with the help of Traviando's event browser and state visualization) for being consistent and as expected. Check for difference between states you would expect to be the same.
• Check if the model is of the kind the does not contain states that are repeatedly visited. This may be due to the very model, due to the use of certain variables as counters, due to a very detailed or very coarse state representation chosen by the simulator or due to the kind of simulation performed, e.g., an analysis with many replicated and short simulation runs.

Verification and Therapy

• Check with event browser where action A happens in the trace and in which context. Check what other actions that are expect to contribute to a cycle do are do not happen afterwards and see if they lead to the expected states. See if any of the state variables are set to disable necessary actions or if enabling conditions and state transformations of actions are performing as expected. If not, double check with the model specification and the conceptual model for consistency. Note that the root cause may not be local to the action that raises this warning!