Make 1D flow domains agnostic of transport model

[ischoegl]

Changes proposed in this pull request

Switch between StFlow and IonFlow in C++ factory constructors. This allows for the following:

• Absorb IonFlow behavior in conventional FreeFlow/UnstrainedFlow/AxisymmetricFlow
• Absorb IonFreeFlame in FreeFlame
• Absorb IonBurnerFlame in BurnerFlame
• Deprecate all "ion" specializations in the user-facing API

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

Closes Cantera/enhancements#165

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

# Instantiate Solution with 'ionized-gas' transport model
gas = ct.Solution('gri30_ion.yaml')
gas.TPX = Tin, p, reactants

# Set up flame object - automatically sets up correct flow domain model
f = ct.FreeFlame(gas, width=width)

Checklist

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

[codecov]

Codecov Report

Merging #1514 (fa2895f) into main (d717e8b) will decrease coverage by 0.05%.
The diff coverage is 44.70%.

❗ Current head fa2895f differs from pull request most recent head 2a9bb1e. Consider uploading reports for the commit 2a9bb1e to get more accurate results

@@            Coverage Diff             @@
##             main    #1514      +/-   ##
==========================================
- Coverage   70.46%   70.42%   -0.05%     
==========================================
  Files         375      375              
  Lines       58405    58437      +32     
  Branches    20899    20917      +18     
==========================================
- Hits        41158    41152       -6     
- Misses      14227    14262      +35     
- Partials     3020     3023       +3     

Impacted Files	Coverage Δ
include/cantera/oneD/IonFlow.h	73.33% <0.00%> (-11.29%)	⬇️
include/cantera/oneD/StFlow.h	100.00% <ø> (ø)
src/oneD/IonFlow.cpp	46.89% <0.00%> (-2.26%)	⬇️
src/oneD/StFlow.cpp	82.18% <6.25%> (-1.98%)	⬇️
src/oneD/DomainFactory.cpp	81.63% <55.55%> (-9.07%)	⬇️
interfaces/cython/cantera/_onedim.pyx	81.18% <57.69%> (-0.77%)	⬇️
interfaces/cython/cantera/onedim.py	82.92% <60.71%> (-0.66%)	⬇️

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

[speth]

Thanks, @ischoegl, I think this makes sense and simplifies flame instantiation a bit. I had just a few suggested changes.

[speth]

This reliance on the specific model name is a little fragile/limiting, in that it doesn't provide a way for any other transport model to be used with IonFlow. I believe the only requirement the IonFlow class puts on the transport model is that it must implement the getMobilities method. Perhaps we can do something like adding a boolean providesGetMobilities() method to Transport that can be reimplemented by any relevant transport model.

[ischoegl]

Valid comment. However, MixTransport defines the function also, which complicates this a bit. As long as "ionized-gas" is the only model that implements this, I believe it's safe as long as it's tested. I added two specific tests for all flame types to test_oneD.cpp, which will fail if any of this is touched.

[ischoegl]

@speth ... thanks for catching the translate_exception - these are nasty crashes.

Regarding your point about the brittle implementation of the IonFlow factory constructor switch, I added a googletest that should be adequate until the point when someone adds a new transport model that is suitable for 1D simulations.