Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add basic operator split capability in ReactingFlow #291

Merged
merged 11 commits into from
Jul 24, 2024

Conversation

trevilo
Copy link
Contributor

@trevilo trevilo commented Jul 23, 2024

This PR adds an operator splitting implementation intended to support stiff reactions. Specifically, we use Lie splitting within ReactingFlow. The 'spatial' terms, specifically advection-diffusion, are discretized with backward Euler. The 'reaction' terms, including the source term in the temperature equation due to chemical reactions, are discretized with forward Euler at a user-specified subdivision of the advection-diffusion time step. This allows the time step seen by the chemistry to be set arbitrarily small, enabling stable integration of stiff reactions, without affecting the time step of the advection-diffusion component of the system.

Sigfried Haering and others added 10 commits July 23, 2024 12:19
Since temperature equation is

rho * Cp * DT/Dt = rhs,

in the operator split method, the temperatureSubstep method must use

dT = dt * rhs / (rho * Cp),

where rhs contains the local terms that have been split out (here just
rxn term from heatOfFormation).

After this fix, using bdfOrder = 1 but otherwise no change to
test/inputs/input.reactSingleRx.ini produces a good match to previous
results.
Current implementation does not support higher order schemes, so be
sure user doesn't run that way.  NB: Required adding the order to the
temporalSchemeCoefficients struct b/c otherwise the model classes (in
particular ReactingFlow here) only know the coefficients, not the
order.  The coefficients cannot be used for this check b/c the first
step is always a BDF1 step.
so that we can choose not to use it.  Previous implementation split
the source terms even when using a single substep.
Since the species ParGridFunction objects (specifically, Yn_gf_ and
Yn_next_gf_) are sized for a single species, but Vector objects (Yn_
and Yn_next_) hold all species, the previous species update in the
operator split scheme was broken.  In particular, the sequence

Yn_next_gf_.SetFromTrueDofs(Yn_);
Yn_next_gf_.GetTrueDofs(Yn_next_);

does behave as intended, meaning that it does not overwrite all
entries of Yn_next_ with the values in Yn_, because Yn_next_gf_ is
only sized for 1 species.

This commit fixes this problem by avoiding use of the species
ParGridFunction objects during the operation.
And move unsteady thermo pressure term into the operator split piece.
@trevilo trevilo added the enhancement New feature or request label Jul 23, 2024
@trevilo trevilo self-assigned this Jul 23, 2024
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
src/reactingFlow.cpp Outdated Show resolved Hide resolved
Mainly updating comments and deleting dead code that was commented out.
@trevilo trevilo marked this pull request as ready for review July 23, 2024 19:16
@trevilo trevilo merged commit 9e98488 into main Jul 24, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant