solvers.SSA

ssa_nrm_refusal(sn)

[OK, REASON] = SSA_NRM_REFUSAL(SN) Whether an EXPLICIT options.method=’nrm’ can answer this model.

NOT SSA_NRM_ELIGIBLE, and the difference is the whole point of having two predicates. SSA_NRM_ELIGIBLE asks whether the NRM should be PREFERRED, and it is deliberately wide: SOLVER_SSA_ANALYZER consults it on the ‘default’ and ‘parallel’ paths to pick an engine. This one asks what a GATE must ask, which is whether the name the caller typed will produce an answer.

The two differ because the explicit ‘nrm’ arm of SOLVER_SSA_ANALYZER FALLS BACK to the serial engine, with a warning, for reneging patience, balking, phase-type service, global dependence and cache retrieval. A model carrying any of those still gets a correct answer under ‘nrm’, so refusing it here would withdraw a row the solver honours – the report would be wrong in the opposite direction.

What is left is the ONE condition that reaches SOLVER_SSA_ANALYZER_NRM and raises there rather than falling back: a scheduling discipline the reaction network has no form for (solver_ssa_analyzer_nrm.m:24, ‘solver_ssa_analyzer_nrm:UnsupportedPolicy’). That is the rule this gate states, and only that one.

The C++ port gates on the wider set ON PURPOSE and is not diverging: its NRM has no fallback arm at all, so every one of the six conditions raises there. Each gate states its own engine’s reach.

solver_ssa_nrm_OMR(sn, options)

SOLVER_SSA_NRM Steady‑state analysis via the Next‑Reaction Method (SSA)

[PI, SSQ, ARVRATES, DEPRATES, SN] = SOLVER_SSA_NRM(SN, OPTIONS) runs a stochastic simulation of the queueing network described in SN for OPTIONS.samples reaction firings using Gibson & Bruck’s Next‑Reaction Method. During the run it:

observes every distinct global state visited and the time spent in it;

accumulates the per‑state propensities of all enabled reactions, including self‑loops (service completions routed back to the same queue).

Outputs

PI – 1×S vector of empirical steady‑state probabilities: (sojourn‑time fractions) for the S unique states;
SSQ – S×(M·R) matrix listing those states row‑by‑row in the: flattened (station, class) order;
DEPRATES – S×(M·R) matrix of total departure rates from each queue: in the corresponding state;

SN – (Possibly updated) network structure.

See also NEXT_REACTION_METHOD.

solver_ssa(sn, init_state, options, eventCache)

[PI,SSQ,ARVRATES,DEPRATES,TRANSYSSTATE,QN,DLYRATES,STARTRATES,PREEMPTRATES,TRANSTARTTAG,TRANPREEMPTTAG]=SOLVER_SSA(QN,OPTIONS)

STARTRATES and PREEMPTRATES are the derived START/PREEMPT rates per unique state, laid out like ARVRATES/DEPRATES: how fast the transitions enabled in that state start a class-r service at a stateful node, or push a class-r job in service there back into the buffer.

TRANSTARTTAG{e} and TRANPREEMPTTAG{e} are the tags of the transition that actually FIRED at step e, as rows [statefulIndex class]. The trace needs them explicitly: @SolverSSA/sample.m rebuilds events from sn.sync{tranSync(e)}, which by construction carries no derived tag.

solver_ssa_analyzer_parallel(sn, init_state, laboptions)

[XN,UN,QN,RN,TN,CN]=SOLVER_SSA_ANALYZER_PARALLEL(SN, INIT_STATE, LABOPTIONS)

Worker-count-invariant parallel SSA.

The simulation budget is split into a FIXED number of independent replications R (laboptions.config.nreplicas). Replication r simulates ceil(samples/R) events and is seeded deterministically with (seed+r-1): inside a parfor body spmdIndex resolves to 1 in solver_ssa, so the effective seed is exactly laboptions.seed+r-1, independent of which worker executes the iteration. The R replications are distributed over whatever workers the parallel pool provides (and run on the client if no pool exists), and the per-replication estimates are averaged.

Because replication r always uses the same seed and sample budget no matter how many workers are available, the returned averages depend only on (seed, samples, R) and are invariant to the worker count. This is the key difference from the previous spmd implementation, whose result varied with the pool size (it both divided the budget by, and seeded labs from, the runtime number of labs).

solver_ssa_findenabled(sn, node_a, enabled_next_states, cur_state, outprob_a, event_a, class_a, isSimulation, node_p, local, outprob_p, event_p, class_p, sync, gsync, depRatesSamples, samples_collected, arvRatesSamples, last_node_a, last_node_p, eventCache, startRatesSamples, preemptRatesSamples): The START/PREEMPT accumulators and per-transition tags mirror the inlined enumeration in solver_ssa.m: this is the SAME enumeration, kept as a function, so tagging only one of the two would make the counters depend on the use_inline performance flag.

solver_ssa_analyzer_serial(sn, init_state, options, isHashed)

[XN,UN,QN,RN,TN,CN,TRANSYSSTATE,TRANSYNC,SN,STARTN,PREEMPTN,TRANSTARTTAG,TRANPREEMPTTAG]=SOLVER_SSA_ANALYZER_SERIAL(SN, OPTIONS)

STARTN and PREEMPTN are the (station x class) service-start and preemption rates, estimated exactly as TN is: the time average of the rate the enabled transitions carry. TRANSTARTTAG/TRANPREEMPTTAG are the per-step tags of the sampled path, used by @SolverSSA/sample.m to emit START and PREEMPT events.

solver_ssa_analyzer_nrm(sn, options): SOLVER_SSA_ANALYZER_NRM Performance indices from SSA/NRM simulation This variant runs the next‑reaction–method SSA on the network SN and returns mean throughput (XN), utilisation (UN), queue length (QN), response time (RN), throughput per station (TN) and class residence time (CN). Results are based on the empirical state probabilities obtained from SOLVER_SSA_NRM. * Only the scheduling policies listed in ALLOWEDSCHED below are supported. Any other policy triggers an error. Cache nodes are not supported in this simplified variant. *

class EventCache

EventCache Event caching utilities for SSA solver optimization

EventCache provides static methods to create and manage event caching for the Stochastic State-space Analysis (SSA) solver. Event caching improves performance by storing computed events to avoid redundant calculations during simulation.

@brief Event caching system for SSA solver performance optimization

The cache stores mappings of state transitions and their associated events, enabling faster simulation execution by reusing previously computed results.

Method Summary

static create(enabled, sn)

CREATE Create an event cache container

@brief Creates a dictionary for event caching if enabled @param enabled Boolean flag to enable/disable caching @param sn Network structure containing model information @return eventCache dictionary instance or empty array

solver_ssa_reachability(sn, options): [SSQ,SSH,QN] = SOLVER_SSA_REACHABILITY(QN,OPTIONS)

ssa_firingdep_refusal(sn)

[OK, REASON] = SSA_FIRINGDEP_REFUSAL(SN) Whether SolverSSA can answer a Petri net whose firing rates depend on the marking (Transition.setFiringRateDependence).

IT CANNOT, UNDER ANY METHOD, AND SAYS SO BY NAME. The NRM builds one constant-propensity reaction per timed mode, so the g(marking) multiplier has no place in it, and the contract the solver is held to (line-test test_spn_firing_dependence, test_ssa_rejects_dependence) is a refusal rather than a nominal-rate answer. The registry has no name for the construct (‘Transition’ and ‘Firing’ are declared and the rule is about the handle behind them), so it is structural.

ONE PREDICATE, THREE CALLERS: SolverSSA.supportsModelMethod answers with it so model.help does not offer any ssa.* row on such a net, solver_ssa_analyzer raises with it before an engine is chosen, and the NRM reaction builder raises with it on the enableChecks=false path.

ssa_nrm_guards(sn)

G = SSA_NRM_GUARDS(SN) The per-feature tests the NRM engine’s dispatch and gate both read.

ONE BODY, THREE CALLERS. SOLVER_SSA_ANALYZER reads the fields INDIVIDUALLY, because its explicit ‘nrm’ arm falls back to the serial engine with a warning that names the offending construct, so it has to know WHICH test failed. SSA_NRM_ELIGIBLE reads them together to answer “should the NRM be preferred”. SSA_NRM_REFUSAL reads only sched, because that is the one condition the explicit arm does not fall back on.

These were local functions of SOLVER_SSA_ANALYZER until 2026-09-05, which is why the eligibility test could not be asked from a gate. Moving them here is what lets all three callers share one definition instead of three copies.

Fields (all true = the NRM can take it):: sched every station’s discipline has a reaction form phase non-exponential service only where every job present is in service renege no station renegs with non-exponential patience balk no balking strategy outside QUEUE_LENGTH gd no global (Whittle) dependence cache every cache configuration (always true; see below) fcr every finite capacity region rule (always true; see below) spn a Petri net the NRM’s reaction builder can read (see below)

solver_ssa_nrm_space(sn, options)

SOLVER_SSA_NRM_SPACE Steady‑state analysis via the Next‑Reaction Method (SSA)

[PI, SSQ, ARVRATES, DEPRATES, SN] = SOLVER_SSA_NRM_SPACE(SN, OPTIONS) runs a stochastic simulation of the queueing network described in SN for OPTIONS.samples reaction firings using Gibson & Bruck’s Next‑Reaction Method. During the run it:

observes every distinct global state visited and the time spent in it;

accumulates the per‑state propensities of all enabled reactions, including self‑loops (service completions routed back to the same queue).

Outputs

PI – 1×S vector of empirical steady‑state probabilities: (sojourn‑time fractions) for the S unique states;
SSQ – S×(M·R) matrix listing those states row‑by‑row in the: flattened (station, class) order;
DEPRATES – S×(M·R) matrix of total departure rates from each queue: in the corresponding state;

SN – (Possibly updated) network structure.