template<int dim, typename NumberType>
class DiFfRG::SolutionSample< dim, NumberType >
A read-only snapshot of the discrete solution, one sample per active cell.
Exists so a model can answer questions about the solution that are not pointwise. The EoM machinery in common/eom.hh drives everything from a pointwise field EoM(x, u), which is enough to locate a minimum but cannot express a feature defined by comparing a cell with its neighbours – a shock, a kink, the edge of a plateau. A model that needs one of those overrides extractor_point (see model/model.hh) and is handed one of these.
Sampling is at cell centres, one entry per active cell, which is the resolution such features are defined at in the first place. Entries are sorted lexicographically by coordinate, so in one dimension they simply run left to right and neighbouring entries are neighbouring cells. In higher dimensions the ordering is well-defined but adjacency is the model's problem.
Like the rest of discretization/common, this assumes the replicated-mesh rung: the mesh is whole on every rank and the solution reaches it through a SolutionView that holds every index, so the sample is built rank-locally and is identical on every rank without communicating.
template<int dim, typename NumberType >
Fill the gradients by central differences between neighbouring samples.
For a builder that can supply values cheaply but not gradients – a finite-volume assembler, whose piecewise-constant shape functions have none – this recovers a usable gradient in O(n) without touching the scheme's reconstruction machinery. It is a plain difference, not the limited slope the scheme itself uses, so it is deliberately NOT what the flux path sees.
Only meaningful in one dimension, where the sorted order is the mesh order; a no-op otherwise.
1.12.0