LINE Solver (C++)
Templated C++ port of the LINE queueing solver
Loading...
Searching...
No Matches
fluid_runner.h File Reference

The fluid solver's outermost entry point: @@SolverFLD/runAnalyzer.m's method resolution over solver_fluid_analyzer.m's dispatch. More...

Include dependency graph for fluid_runner.h:

Go to the source code of this file.

Namespaces

namespace  line
namespace  line::fluid

Functions

std::vector< std::string > line::fluid::fluid_list_valid_methods ()
 Port of SolverFLD.listValidMethods.
void line::fluid::fluid_check_method (const std::string &method)
 Port of runAnalyzerChecks' method gate: an unlisted method is refused.
template<class T>
FluidSolution line::fluid::solver_fluid_run_analyzer (const qn::NetworkStruct< T > &sn, const FluidOptions &opt, qn::NetworkStruct< T > *sn_out=nullptr, qn::NetworkStruct< T > *refreshed_out=nullptr, solvers::CacheMetrics< T > *cache_out=nullptr)
 Port of @@SolverFLD/runAnalyzer.m: resolve the method, route to the function the reference routes to, correct once.
template<class T>
std::vector< FluidTranPointline::fluid::solver_fluid_run_transient (const qn::NetworkStruct< T > &sn, const FluidOptions &opt, std::size_t points=101)
 -a tran / @@SolverFLD/getTranAvg with the method HONOURED, which is the one place the reference does not force closing.
template<class T>
std::vector< std::vector< FluidPassage > > line::fluid::solver_fluid_cdf_respt (const qn::NetworkStruct< T > &sn, const FluidOptions &opt, std::size_t points=201)
 Port of @@SolverFLD/getCdfRespT: the response-time law of every (station, class) pair, read off the marked-fluid trajectory started from the steady state.
template<class T>
std::string line::fluid::solver_fluid_export_odes (const qn::NetworkStruct< T > &sn, const FluidOptions &opt, const std::string &notation="scalar", const std::string &model_name="model")
 Port of @@SolverFLD/exportODEs.m at the runner's own method resolution, so the exported system is the one solver_fluid_run_analyzer would integrate.

Detailed Description

The fluid solver's outermost entry point: @@SolverFLD/runAnalyzer.m's method resolution over solver_fluid_analyzer.m's dispatch.

WHY THIS IS A SEPARATE HEADER AND NOT ANOTHER BRANCH IN fluid_dispatch. Three of the reference's branches are ports that sit ABOVE solver_fluid.h and include it – solver_fluid_closing.m (fluid_closing.h), solver_fld_cacheqn_analyzer.m (fluid_cacheqn.h) and @@SolverFLD/exportODEs.m (fluid_export_odes.h). A dispatcher inside solver_fluid.h therefore cannot call them without a cyclic include, and lowering them into it would put three unrelated solvers in one file. The routing goes here instead, in the one place that may include all four, which is also the pattern the CTMC, MAM, MVA, NC and SSA runners follow.

WHAT fluid_dispatch STILL REFUSES, and why that is not a duplicate gate. It cannot see the cache analyzer, so a Cache model reaching it directly is refused BY NAME rather than solved by the wrong method; the refusal names this header as the entry point that does route it. Both are true statements about the function that carries them.

THE CORRECTION IS APPLIED ONCE, HERE. solver_fluid_analyzer.m runs its utilization and response-time correction after the method switch and on every branch alike, and the per-method functions it calls return the uncorrected table for exactly that reason. solver_fluid is itself that switch plus the correction, so the branches routed around it are corrected here and the ones routed through it are not corrected twice.

Definition in file fluid_runner.h.