You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if no solution is found, re-run the simulation with the energy equation disabled
if a solution is found, re-run with the energy equation enabled
For a counterflow flame, finding the extinct flame solution counts as a successful solution, so the second step of trying to solve without the energy equation will never be exectuted. There are however cases, where this improves the convergence to the non-extinct flame solution.
Motivation
Consider the attached counterflow flame python script direct.txt (I cannot attach *.py files), where the fuel and oxidizer nozzles have the same velocity U. The counterflow flame is computed for 26 different velocites U from 1 to 20 m/s. For each simulation, a new counterflow flame is created and each simulation begins with the initial guess provided by the auto solution strategy. According to this script, extinction occurs at around U = 8 m/s.
Instead of running the simulations with the initial guess from auto, they are run from the flame solution at the previous velocity in the attached script continuation.txt. With this strategy, extinction occurs at around U = 16 m/s.
if not solved or self.extinct():
if self.extinct():
self.set_initial_guess(*self._initial_guess_args,**self._initial_guess_kwargs)
has been made.
After making this change and running the script direct.txt again, a similar extinction strain at U = 16 m/s as from the script continuation.txt is found. The comparison is plotted here:
Before making a pull request, I wanted to discuss this change here first:
Do you see any unintended side-effects from this change?
Looking at the temperature plot, the modified code (dashed black line) creates one point at U ~ 7 m/s with max(T)=1300 K. I do not understand how this solution can be found.
Hi @g3bk47, thanks for looking into this, and sorry for the delay in responding. I think this change makes a lot of sense. Even if the continuation approach is likely always going to be better at finding the non-extinct solution, it's still worth making it easier to find that solution under a wider range of conditions.
Abstract
A common application for counterflow flames is to find the extinction strain. For any type of 1D flame, the following solution strategy is applied:
For a counterflow flame, finding the extinct flame solution counts as a successful solution, so the second step of trying to solve without the energy equation will never be exectuted. There are however cases, where this improves the convergence to the non-extinct flame solution.
Motivation
Consider the attached counterflow flame python script direct.txt (I cannot attach *.py files), where the fuel and oxidizer nozzles have the same velocity U. The counterflow flame is computed for 26 different velocites U from 1 to 20 m/s. For each simulation, a new counterflow flame is created and each simulation begins with the initial guess provided by the
auto
solution strategy. According to this script, extinction occurs at around U = 8 m/s.Instead of running the simulations with the initial guess from
auto
, they are run from the flame solution at the previous velocity in the attached script continuation.txt. With this strategy, extinction occurs at around U = 16 m/s.By changing the solution strategy slightly, both scripts yield similar results. The required modification has to be made here https://github.com/Cantera/cantera/blob/main/interfaces/cython/cantera/_onedim.pyx#L1241, where the change from
to
has been made.
After making this change and running the script
direct.txt
again, a similar extinction strain at U = 16 m/s as from the scriptcontinuation.txt
is found. The comparison is plotted here:Before making a pull request, I wanted to discuss this change here first:
The reaction mechanism from the example script is CH4.txt (rename to CH4.yaml).
I ran the scripts with Cantera 3.0.0a1.
The text was updated successfully, but these errors were encountered: