|
PICurv 0.1.0
A Parallel Particle-In-Cell Solver for Curvilinear LES
|
PICurv couples a particle scalar micromixing model (IEM-style) with particle statistics postprocessing. Eulerian field statistics are a separate system with its own configuration and state; see Field Statistics.
For Psi, UpdateParticleField uses:
\[ \frac{d\Psi}{dt} = -\Omega(\Psi-\langle\Psi\rangle), \qquad \Omega = C_{IEM}\,\frac{\Gamma_{eff}}{\Delta^2}, \qquad \Delta^2\approx V^{2/3}. \]
Closed-form update implemented in code:
\[ \Psi^{n+1}=\langle\Psi\rangle + (\Psi^n-\langle\Psi\rangle)e^{-\Omega\Delta t}. \]
Code touchpoints:
IEM update requires:
user->lPsi) and Jacobian (user->lAj) for volume scaling.This means scatter/interpolation order matters: stale Eulerian means produce stale IEM forcing.
Current primary reduction kernel:
Implemented MSD physics includes:
\[ D = \frac{1}{Re\,Sc}, \qquad r_{theory} = \sqrt{6Dt}, \]
with global MPI reductions and CSV output per statistics call.
Eulerian field statistics are configured at monitor.yml -> field_statistics, accumulate weighted centered moments while the solver runs, and are derived into Reynolds stresses, RMS, turbulent kinetic energy, and fluxes by post.yml -> field_statistics. Field Statistics is the full contract.
Particle MSD stays under the postprocessor statistics_pipeline described above. It is not an Eulerian field window, shares no accumulator state, and is configured separately. The two are kept apart deliberately so a particle reduction and a resolved-turbulence average are never conflated.
Psi is the field where the two subsystems meet: it is a particle-carried scalar projected onto the grid, and the projected field can itself be accumulated as a statistics window when particles are active.
"Averaging" appears in multiple contexts:
Treat these as distinct workflows with different configuration points.
This page describes IEM Mixing and Statistical Averaging within the PICurv workflow. For CFD users, the most reliable reading strategy is to map the page content to a concrete run decision: what is configured, what runtime stage it influences, and which diagnostics should confirm expected behavior.
Treat this page as both a conceptual reference and a runbook. If you are debugging, pair the method/procedure described here with monitor output, generated runtime artifacts under runs/<run_id>/config, and the associated solver/post logs so numerical intent and implementation behavior stay aligned.