Improve post-processing.

[FreddieWitherden]

This greatly improves post-processing capabilities. Specifically

• Support is added for analysing time series data and the HDF5 format used for this has been reworked (CSV remains unchanged).
• Time-average stats can now be specified from sets of pre-defined stats packages. These packages are also used for post-processing quantities on export.
• Gradient data can be reconstructed in post with appropriate treatment for walls. This is mostly used for budget terms but can be useful elsewhere.
• Force coefficients can be directly extracted as $C_L$ and $C_D$ so long as appropriate reference areas and vectors are provided in the .ini file.

[kaschau]

The boundary treatment post-hoc gradient reconstruction is skipped for volume exports and the sampler CLI. The wall/BC refinement of the flux-point deltas in FieldRecovery only runs if the mesh has boundary connectivity: _bc_state_info iterates self.mesh.bcon. However, the volume VTK writer loads the mesh with construct_con=False (BaseWriter.needs_con = False), as does sampler sample, so bcon is empty on these paths and deltas() applies no boundary correction. The only thing that populates bcon is the boundary writer, so in practice the wall treatment never fires for volume exports of budget terms, nor for anything in 2D which might be by design if we are keeping the 'no boundary export for 2d' rule for these calculations.

[FreddieWitherden]

Partly by design. The reconstruction can be a bit on the expensive side and really only makes a big difference at boundaries. Wasn't sure if we want to push it out more widely to volumes (although here the preferred approach is to have gradient data available in the solution itself, so the deficit only covers solutions without gradients and time averages requiring derived quantities). Fiddly bit is we can't at the moment be more granular around if we want connectivity or not (and this also comes with an up front cost). So we'd pay for connectivity even in the common "volume export with nothing fancy" case.

Am open to suggestions though.

[kaschau]

Some friction points for later selectable EOS work:

1.) auxvars being strings-only. TPG EOS needs pointwise γ(T, Y for multicomp) for things like mach/p0. we could allow auxvars entries (and stats-table derived quantities) to be callables over the field namespace, not just expression strings.

2.) stats_tables is a class attribute. For multi comp, the right table set depends on config (cpg vs tpg, transport model). could make it a classmethod taking cfg.

[FreddieWitherden]

Point 2 is a no brainer, and easy to fix. For point 1 I am wondering if the DSL rewrite comes through then we'll have a full parsing infrastructure so returning function calls becomes an option (parsed later).

[kaschau]

Point 2 is a no brainer, and easy to fix. For point 1 I am wondering if the DSL rewrite comes through then we'll have a full parsing infrastructure so returning function calls becomes an option (parsed later).

yes I think its totally fine, there are bound to be other minor tweaks and they can wait for larger enhancements to land.

[kaschau]

We also need to expose volume/boundary postproc adapters to soln for any metadata they require, like in NIRF

[FreddieWitherden]

Have pushed some improvements, but still need to address your points. Key thing is we now always compute boundary connectivity in the reader (it's cheap) and so can always do recent reconstruction.

I'll sort out the stats table stuff tomorrow.

[kaschau]

Perhaps it can be added in the NIRF work, but we have to allow for the NIRF plugin to run first, so the downstream plugins all compute relative to that modified data. currently it looks like the ordering of CLI fields is enforced, but something more explicit might be the right call so that doesnt fall on the user.

And I think this is reasonable, but we cannot provide lab frame vector/tensor stats from unsteady motion without pretty significant modification and costs.

Also, do we want a postproc dependency chain still? if we want to expose other post proc output to other plugins? they are available in the adapter, just not guaranteed by any ordering.

[FreddieWitherden]

We can reintroduce dependency chains if the need arises (we know how to do it). For NIRF we may want a pre-post-proc capability so it can inject itself right at the start.

What to do in terms of some accumulated quantities when there is motion is still something of an open conceptual question for me. More thought certainly needed about what these stats mean, what people want, and how we can provide it.

[kaschau]

We can reintroduce dependency chains if the need arises (we know how to do it). For NIRF we may want a pre-post-proc capability so it can inject itself right at the start.

What to do in terms of some accumulated quantities when there is motion is still something of an open conceptual question for me. More thought certainly needed about what these stats mean, what people want, and how we can provide it.

luckily scalar invariants are fine as is which I think are the heavy hitters. so I agree we need to see what people are asking for first.