 |
LINE Solver (C++)
Templated C++ port of the LINE queueing solver
|
|
LINE Solver (C++)
Templated C++ port of the LINE queueing solver
|
SolverAUTO.listValidMethods: the method names THIS MODEL can actually run. More...
#include <algorithm>#include <array>#include <cctype>#include <cmath>#include <cstddef>#include <initializer_list>#include <stdexcept>#include <string>#include <vector>#include "line/lang/qn/feature_set.h"#include "line/util/error.h"#include "line/lang/qn/network_struct.h"#include "line/lang/qn/solver_feature_sets.h"#include "line/solvers/ag/solver_ag_runner.h"#include "line/solvers/auto/solver_auto.h"#include "line/solvers/ba/solver_ba_runner.h"#include "line/solvers/ctmc/solver_ctmc_analyzer.h"#include "line/solvers/ctmc/solver_ctmc_cftp.h"#include "line/solvers/ctmc/solver_ctmc_mdd_analyzer.h"#include "line/solvers/fluid/fluid_runner.h"#include "line/solvers/mam/solver_mam_runner.h"#include "line/solvers/mva/solver_mva_runner.h"#include "line/solvers/nc/solver_nc_runner.h"#include "line/solvers/ssa/ssa_dispatch.h"#include "line/solvers/wrappers/jmt/solver_jmt.h"#include "line/solvers/wrappers/ldes/ldes_options.h"#include "line/solvers/wrappers/qns/solver_qns.h"Go to the source code of this file.
Classes | |
| struct | line::autosolver::SolverCandidate |
| One row of auto_find_solver: a (family, method) pair this model can be asked for, whether it runs, what kind of answer it returns and which measures it can report. More... | |
Namespaces | |
| namespace | line |
| namespace | line::autosolver |
Functions | |
| std::vector< std::string > | line::autosolver::auto_network_family_names () |
| The method families that solve a flat Network, in SolverAUTO.familyNames' own order – which is also the order an unqualified algorithm name is looked up in, so it is not arbitrary. | |
| std::vector< std::string > | line::autosolver::auto_method_alias_prefixes (const std::string &family) |
| The prefixes under which a family advertises a SECOND SPELLING of a method it already declares plainly. | |
| bool | line::autosolver::auto_is_method_alias (const std::string &family, const std::string &name, const std::vector< std::string > &declared) |
| Is name a second spelling of another method this family declares? | |
| template<class T> | |
| std::vector< std::string > | line::autosolver::auto_family_methods (const std::string &family, const qn::NetworkStruct< T > &sn) |
| The methods a family declares ON THIS MODEL, empty when it declares none. | |
| template<class T> | |
| std::string | line::autosolver::auto_family_refusal (const std::string &family, const qn::NetworkStruct< T > &sn, const std::string &method) |
| Solver.supportsModelMethod for a family method name: may THIS model run THIS method of THIS family? | |
| template<class T> | |
| bool | line::autosolver::auto_family_supports (const std::string &family, const qn::NetworkStruct< T > &sn, const std::string &method) |
| std::vector< std::string > | line::autosolver::auto_metric_groups () |
| The measure groups auto_find_solver reports on, in report order. | |
| std::string | line::autosolver::auto_metric_group_of (const std::string &name) |
| The measure group an accessor belongs to, "" when the name belongs to none. | |
| std::vector< std::string > | line::autosolver::auto_family_metrics (const std::string &family) |
| The measure groups a method family can answer. | |
| bool | line::autosolver::auto_is_stochastic_method (const std::string &family, const std::string &method) |
| Solver.isStochasticMethod for a family method name: does this method return seed-dependent estimates? | |
| std::string | line::autosolver::auto_method_class (const std::string &family, const std::string &method, bool is_stochastic, bool is_product_form, bool is_qbd_shape, bool has_cache=false) |
| What KIND of answer a method returns: "exact", "approx", "bound" or "simulation". | |
| template<class T> | |
| std::vector< SolverCandidate > | line::autosolver::auto_find_solver (const qn::NetworkStruct< T > &sn, const std::string &metric=std::string(), bool show_all=false) |
| SolverAUTO.findSolver: which solvers and solver methods can analyze this model, and for the ones that cannot, why not. | |
| template<class T> | |
| std::vector< SolverCandidate > | line::autosolver::auto_find_method (const qn::NetworkStruct< T > &sn, const std::string &metric=std::string(), bool show_all=false) |
| Alias of auto_find_solver: the same table, asked for by method. | |
| template<class T> | |
| std::vector< SolverCandidate > | line::autosolver::auto_help (const qn::NetworkStruct< T > &sn, const std::string &metric=std::string(), bool show_all=false) |
| Alias of auto_find_solver: what can this model be solved with? | |
| std::string | line::autosolver::auto_find_solver_table (const std::vector< SolverCandidate > &rows) |
| The rows as an aligned text table, the form the CLI and a console caller want. | |
| template<class T> | |
| std::vector< std::string > | line::autosolver::auto_list_valid_methods (const qn::NetworkStruct< T > &sn) |
| SolverAUTO.listValidMethods: every method name this model can be asked for. | |
SolverAUTO.listValidMethods: the method names THIS MODEL can actually run.
WHY IT IS A SEPARATE HEADER. solver_auto.h is deliberately light – a struct, a ranking table and the feature sets – and it is included by the CLI, the facade, the examples and test_all_headers. Answering this question needs every family's method registry, i.e. the MVA, NC, CTMC, fluid, MAM, BA, SSA, LDES, JMT and QNS runners, so putting it there would make a heavy include of a cheap one for every caller that only wants the ranking.
THE GATE IS THE FEATURE SET, asked of every candidate rather than of the first feasible one. auto_supports already asks it for the seven ranked slots, and it is the same question chooseSolverRanked asks before delegating: is every feature the model uses declared by the solver that would run this method? A family whose feature set refuses the model contributes nothing, and a method whose own set refuses it is not offered. Both matter, because a per-method set is where the deltas live – MVA's rqna consumes MAP arrivals that the rest of the envelope does not, MAM's LoadDependence holds only for the methods that read lldscaling.
WHAT A FLAT FEATURE SET CANNOT SAY, and is therefore asked separately, exactly as the reference's supportsModelMethod overrides do: product form 'exact' is not exact without one (SolverMVA's OI/PAS stations excepted); folded into auto_supports a chain that fits the CTMC slot is screened for state-space size a binding buffer setCapacity/classCap, which MVA, NC, FLD and QNS refuse through check_binding_capacity and no feature name describes the model SHAPE mva::list_valid_methods(L) and ba::list_valid_methods(L) are themselves model-aware: the queueing-system closed forms are offered on a two-station open model and nowhere else, the QRF reduction bounds on a single-class closed network of single servers, the three open-network bounds on a fully open one. Asking the registry for the model is what keeps that rule in one place.
A FAMILY WHOSE EVERY METHOD IS REFUSED LOSES ITS BARE TOKEN TOO: nc alone delegates to SolverNC, which is exactly the rejection the per-method gate just returned.
WHAT IS NOT LISTED, and why each is a token this port would refuse anyway: ln, env, lqns, uq take a LayeredNetwork, an Environment or an inner-solver factory rather than a Network. The reference's own buildFamilySolver cannot construct them from here either, and its familyAcceptsModelClass drops them. ldes without an engine auto_supports folds auto_solver_is_available in, and the CLI refuses --method ldes by name when no engine is found beside the binary. Listing it there would be a claim the very next call denies. JMT IS LISTED although it is not a ranked candidate. It has no slot in AutoSolver – the reference removed it as one, LDES subsuming its feature set – but -s auto --method jmt reaches it as an explicit method name, and listValidMethods answers about the method names the caller may ask for, not about the ones the ranking would pick.
THERE IS NO list_all_methods TWIN. In the reference the model-independent list exists so that a method-NAME check can reject an unknown method name with the family's own explanation rather than a flat "unsupported"; auto_resolve_token here performs no such check – it splits the method name and lets the family refuse the submethod by name – so a second list would have no caller.
Definition in file auto_methods.h.
1.18.0