Application Reference Architecture
The idea of such an architecture rised when we noticed that the
ApplicationExamples directory got quite crowdy and we need some more structured way of organizing our demonstrator applications.
What Sven observes every ExaHyPE Application has
Inflation of plotters
We notice a big number of generic plotters. They are typically:
Plotter0: The plain output quantities:
outputQuantities = Q;, ie the conserved variables.
Plotter1: All integrations (
TimeSeriesReductions) for all conserved and _ primitive_ variables as well as for the errors between exact and numerical values. Here we have a mapping of the numerical indices of the variables to the actual names (example).
Plotter2: The plain output quantities, filtered to primitive ones:
outputQuantities = con2prim(Q), ie the primitive variables.
Plotter3: The exact output quantities recomputed at time
outputQuantities = exactSolution(x,t), ie. the conserved exact variabels.
Plotter4: The pointwise difference between the evolved and exact quantities, ie.
outputQuantities = Q - exactSolution(x,t).
Plotter5: The relative pointwise differente between evolved and exact quantities, ie.
outputQuantities = (Q - exactSolution(x,t)) / exactSolution(x,t).
I stick to this fixed, but arbitrary numbering scheme amongst the applications but apparently it is quite unflexible at is it not possible to disable
Plotter3 without changing the overall numbering. We should move from numeric plotter labeling to actual labels.
The integrations code (
TimeSeriesReductions) is the same in all applications. It should be moved to the ExaHyPE core.
Queried initial data
Accessing user specified constants in the spec file still does not work correctly, so there is a number of patch code which can access the environment variables instead. In all applications we have multiple initial data examples for a given PDE. This will always remain as we will always have lot's of sources for initial data.
The integration of exact boundary values is currently the same in all applications. What users typically want to do is to specify somewhere if they want
BC. This is a typical run-time choice so there should be all possibilities already in the code. Another thing for redundancy we currently have as the implementation is always the same.