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

The batch-arrival and batch-service queues of the MAM solver, and the two finite-capacity helpers solver_mam_basic.m shares with them: solver_mam_bmap_map_1.m, solver_mam_map_bmap_1.m, mam_detect_mmck.m and mam_truncate_renorm.m. More...

#include <algorithm>
#include <cmath>
#include <cstddef>
#include <string>
#include <type_traits>
#include <vector>
#include "line/api/mam/map_moment.h"
#include "line/api/mam/mmap_lambda.h"
#include "line/api/mam/mmapph1fcfs.h"
#include "line/api/mam/qbd_r.h"
#include "line/lang/qn/network_struct.h"
#include "line/lib/smc/etaqa.h"
#include "line/solvers/mam/solver_mam_basic.h"
#include "line/util/error.h"
#include "line/util/linalg.h"
#include "line/util/matrix.h"
Include dependency graph for solver_mam_bmap.h:

Go to the source code of this file.

Classes

struct  line::mam::MmckDetection< T >
 What mam_detect_mmck returns; muRate is meaningful only when isMmck. More...
struct  line::mam::BmapMap1Blocks< T >
 The level blocks of solver_mam_bmap_map_1.m. More...
struct  line::mam::MapBmap1Blocks< T >
 The level blocks of solver_mam_map_bmap_1.m. More...
struct  line::mam::BmapQueueResult< T >
 What both reference files return once the ETAQA solve has run. More...

Namespaces

namespace  line
namespace  line::mam

Functions

template<class T>
MmckDetection< T > line::mam::mam_detect_mmck (const qn::NetworkStruct< T > &L, std::size_t ist, const Mmap< T > &arv)
 Port of mam_detect_mmck.m: is the exact M/M/c/K closed form legitimate at this station?
template<class T>
basic_detail::TruncRenorm< T > line::mam::mam_truncate_renorm (const Mmap< T > &arv, const std::vector< PhService< T > > &svc, std::size_t capK)
 Port of mam_truncate_renorm.m: the finite-buffer marginal of an MMAP[K]/PH[K]/1 FCFS queue, by truncation and renormalization.
template<class T>
BmapMap1Blocks< T > line::mam::solver_mam_bmap_map_1_blocks (const std::vector< Matrix< T > > &D, const Map< T > &service)
 Port of the block assembly and the stability test of solver_mam_bmap_map_1.m.
template<class T>
MapBmap1Blocks< T > line::mam::solver_mam_map_bmap_1_blocks (const Map< T > &arrival, const std::vector< Matrix< T > > &D)
 Port of the block assembly, the generator validation and the stability test of solver_mam_map_bmap_1.m.
template<class T>
BmapQueueResult< T > line::mam::solver_mam_bmap_map_1 (const std::vector< Matrix< T > > &D, const Map< T > &service, std::size_t nMoments=3)
 Port of solver_mam_bmap_map_1.m, mean measures included.
template<class T>
BmapQueueResult< T > line::mam::solver_mam_map_bmap_1 (const Map< T > &arrival, const std::vector< Matrix< T > > &D)
 Port of solver_mam_map_bmap_1.m, mean measures included.

Detailed Description

The batch-arrival and batch-service queues of the MAM solver, and the two finite-capacity helpers solver_mam_basic.m shares with them: solver_mam_bmap_map_1.m, solver_mam_map_bmap_1.m, mam_detect_mmck.m and mam_truncate_renorm.m.

NEITHER SOLVER IS A CONVERSION. Both take the batch process AS a batch process and build the exact level-transition blocks of the resulting chain; neither one replaces a BMAP by a MAP of the same rate, and neither is expressible as the other. What differs between them is the SHAPE of the chain, and that shape is forced by which side carries the batches:

BMAP/MAP/1 the level rises by the batch size and falls by exactly one, so the chain is M/G/1-TYPE (skip-free to the left) MAP/BMAP/1 the level rises by exactly one and falls by the batch size, so the chain is GI/M/1-TYPE (skip-free to the right)

Both block assemblies are EXACT: no batch is ever resolved into independent single arrivals, which is the approximation that would destroy the whole point. A batch of k is one epoch at which k jobs appear together, and the queue-length law it induces is not the law induced by k Poisson epochs of the same total rate – the batch correlates the arrivals perfectly, so the second moment of the queue length is strictly larger. That is why A_{k+1} moves the level by k in one step rather than being folded into A_2.

WHERE AN APPROXIMATION DOES ENTER, it is at the BOUNDARY of the GI/M/1-type chain, and it is a clipping rather than a loss. A batch service of size k at a level j < k cannot take the level to j - k, so solver_mam_map_bmap_1.m routes every batch of size k >= j from level j to level ZERO:

B_{j+1} = sum_{k >= j} I (x) D_k

and at level 0 it folds the whole service mass back onto the local block. THE TAIL IS LUMPED, NOT DISCARDED, which is the same convention State.signalBatchPMF uses for a negative signal (see signal_batch_pmf in lang/qn/state_events.h: the whole tail P(B >= n) is assigned to "remove all n"). The invariant it buys is that the boundary rows still sum to zero, so no probability is created or destroyed by the clipping; the price is that the boundary over-reports emptying events relative to a chain that could represent the missing customers.

mam_truncate_renorm uses the OPPOSITE convention on purpose, and the contrast is the reason both are in this header. It truncates the marginal queue length at the buffer capacity and RENORMALIZES, so the tail above capK is deleted and its mass is redistributed over levels 0..capK in proportion, rather than piled onto level capK. For an M/M/1 input that is not an approximation at all – the M/M/1/K law IS the truncated renormalized geometric – which is what makes it the right convention for a buffer, where a blocked arrival leaves the system rather than joining at the top. Lumping would instead report a boundary mass that no finite-buffer queue has.

THE MEAN MEASURES ARE THE ETAQA SOLVE, and both reference files hand it to third-party MAMSolver: MG1_G_ETAQA, MG1_pi_ETAQA and MG1_qlen_ETAQA on the M/G/1-type side, GIM1_R_ETAQA, GIM1_pi_ETAQA and GIM1_qlen_ETAQA on the GI/M/1-type one, routing in turn into MG1_CR (Bini-Meini cyclic reduction with the shift technique and FFT polynomial products) and GIM1_R (the Bright/Ramaswami dual plus functional iterations). All of it is now ported, under lib/smc/mg1.h and lib/smc/etaqa.h, so these two entry points answer instead of refusing. Read those headers before touching the numbers: the ported code reproduces several reference defects verbatim and says which.

ARITHMETIC. The block assemblies are Kronecker products and one stationary solve, so they are exact at Rational and are NOT gated. The ETAQA solve on top of them is DOUBLE ONLY – LAPACK eigenvalues in the caudal and decay bisections, a complex FFT in cyclic reduction, an SVD in the rank test that picks the redundant column – so solver_mam_bmap_map_1 and solver_mam_map_bmap_1 refuse at any other arithmetic rather than down-convert behind the caller's back. mam_truncate_renorm is gated too, because MMAP[K]/PH[K]/1 runs the ADDA doubling iteration.

Definition in file solver_mam_bmap.h.