Simplify BurnerFlame simulations

[ischoegl]

Changes proposed in this pull request

Unstrained flames have historically been implemented as axisymmetric flames where 'lambda' was used to specify the mass flow rate implicitly (lambda was propagated left-to-right and velocity propagated right-to-left), which leads to confusing boundary conditions (see #1533). The calculation also involves 'V' (which is zero) for the calculation of continuity, which is certainly not intuitive. Beyond, 'V' was also integrated for free flames, although it is by definition zero.

This PR removes the dependency on 'lambda' and 'V', and instead propagates information on mass flow rate left-to-right directly for the 'U' solution component, meaning that 'lambda'/'V' entries are no longer used for unconstrained flames (i.e. BurnerFlame and FreeFlame variants).

In addition:

• simplify logic used for the evaluation of boundary conditions
• only evaluate 'V' for strained flames
• deprecate 'left' outlets, as they are untested and unlikely to work, i.e. only support 'right-to-left' flow for strained flames

If applicable, fill in the issue number this pull request is fixing

Closes #1533

If applicable, provide an example illustrating new features this pull request is introducing

Checklist

• [x] The pull request includes a clear description of this code change
• [x] Commit messages have short titles and reference relevant issues
• [x] Build passes (scons build & scons test) and unit tests address code coverage
• [x] Style & formatting of contributed code follows contributing guidelines
• [x] The pull request is ready for review

[codecov[bot]]

Codecov Report

Merging #1555 (0260cab) into main (a900edf) will increase coverage by 0.06%. Report is 37 commits behind head on main. The diff coverage is 77.63%.

@@            Coverage Diff             @@
##             main    #1555      +/-   ##
==========================================
+ Coverage   70.54%   70.61%   +0.06%     
==========================================
  Files         379      379              
  Lines       59110    59135      +25     
  Branches    21232    21252      +20     
==========================================
+ Hits        41698    41757      +59     
+ Misses      14338    14305      -33     
+ Partials     3074     3073       -1     

Files Changed	Coverage Δ
src/oneD/Sim1D.cpp	69.20% <ø> (-1.23%)	:arrow_down:
src/oneD/Boundary1D.cpp	62.05% <58.97%> (+6.66%)	:arrow_up:
src/oneD/StFlow.cpp	81.88% <96.77%> (-0.30%)	:arrow_down:
include/cantera/oneD/Boundary1D.h	57.89% <100.00%> (+8.91%)	:arrow_up:
include/cantera/oneD/StFlow.h	100.00% <100.00%> (ø)
src/oneD/refine.cpp	82.26% <100.00%> (+1.41%)	:arrow_up:

... and 24 files with indirect coverage changes

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ischoegl]

Rebased after merge conflict after #1568; i.e. this is ready for a review.

[ischoegl]

Thanks for the suggestions, @speth! I addressed all comments, and removed support for left outlets. I suspect that there may be some other issues for right-to-left stagnation flow, but didn't test as this goes beyond the original intent of this PR (which was to untangle boundary conditions for unstrained flow).

One upside is that with this change, it becomes possible - for unstrained cases that do not involve electric fields - to use up to three solution array entries to implement custom equations in overloaded StFlow classes. For example in #1510, a c_offset_Uo could use an existing unused component (although I'm not advocating for this). After 3.0 is out, it would also be possible to not allocate memory for unused components altogether, although this would require significant changes.

[speth]

After 3.0 is out, it would also be possible to not allocate memory for unused components altogether, although this would require significant changes.

Yeah, it would be nice to be more flexible about the state vector components, and have that be determined based on the configuration / domain types. One reason I've hesitated about doing this is that there may be a performance hit in having c_offset_Y and company not being compile-time constants. These variables get used a lot in the evaluation of the governing equations, so I think it's possible this matters, but it also may not.