model.json writers for a LayeredNetwork, a Workflow and an Environment: the layered2json, workflow2json and environment2json branches of linemodel_save.m, and the inverses of lqn_json_reader.h, workflow_reader.h and environment_reader.h. More...

#include <cmath>
#include <fstream>
#include <iostream>
#include <map>
#include <string>
#include <vector>
#include "line/io/network_writer.h"
#include "line/lang/lang_types.h"
#include "line/lang/lqn/lqn_reader.h"
#include "line/lang/qn/environment.h"
#include "line/lang/workflow/workflow.h"
#include "line/util/error.h"

Include dependency graph for linemodel_writer.h:

Namespaces
namespace	line
	Conservation laws of a layered queueing network, enumerated from its structure.
namespace	line::io

Functions
template<class T>
detail::json	line::io::lqn_model_to_json (const lqn::LqnModel< T > &m)
	layered2json: the model object of a LayeredNetwork document.
template<class T>
detail::json	line::io::workflow_to_json (const workflow::Workflow< T > &wf)
	workflow2json: the model object of a Workflow document.
template<class T>
detail::json	line::io::environment_to_json (const env::Environment< T > &e)
	environment2json: the model object of an Environment document.
detail::json	line::io::linemodel_envelope (const detail::json &model)
	The {format, version, model} envelope around a model object, with the wire's non-finites.
void	line::io::write_linemodel_json (const detail::json &root, const std::string &path)
	Write an envelope, indented as write_network_json indents it.

Detailed Description

model.json writers for a LayeredNetwork, a Workflow and an Environment: the layered2json, workflow2json and environment2json branches of linemodel_save.m, and the inverses of lqn_json_reader.h, workflow_reader.h and environment_reader.h.

A Network is written by network_writer.h, which the Environment writer reuses for every stage.

WHICH SPELLING. The four codebases' writers disagree on a few optional keys, and every reader accepts the union. Where they disagree this writer takes the form every reader decodes to the same value:

host multiplicity/scheduling/quantum/speedFactor always written (Python, JAR); MATLAB omits the defaults, and the JAR and native readers default them differently task multiplicity/scheduling, call mean always written (Python, JAR) task think time thinkTime plus thinkTimeMean/thinkTimeSCV (Python, JAR) activity hostDemand always written, an Immediate as {"type":"Immediate"} (Python, JAR) ItemEntry accessProb a DiscreteSampler object over x = 1..n; the JAR reads only the object form, and Python's bare array is unreadable there entry forwarding, activity thinkTime JAR keys, read by the JAR and C++ readers precedences the TYPED form (type + activities), as MATLAB and Python write it Loop loopCount written whenever the count is declared, as MATLAB does AND-join quorum preParams: [q], only when a quorum is set, as MATLAB does task priority, activity callOrder written when not the default (0, STOCHASTIC), as the JAR does

WHAT IS DROPPED. An entry's type (PH1PH2/NONE) and a host declared as Host rather than Processor have no key in any codebase or in the schema; no solver reads either, so the document reloads as the same model and they are left out rather than refused.

WHAT IS REFUSED. An LqnModel field with no wire key in ANY codebase's reader is refused by name rather than dropped, because a document that reloads as a different model is worse than no document: a phase-2 activity, a call group (RROBIN/JSQ), delayed-hit retrieval, the load/class/joint dependence tables and server pools. An Environment stage holding a LayeredNetwork is refused too, since its LqnStruct cannot be turned back into the declared model and no reference writer serializes it.

KEY ORDER is alphabetical, since nlohmann::json keeps objects sorted, where the MATLAB and Python writers keep insertion order. JSON objects are unordered and every reader looks keys up by name, so the order carries no meaning.

Definition in file linemodel_writer.h.

Namespaces

Functions

Detailed Description