Surface reactions were not being written to the CTI file if there were no
gas-phase reactions present.
Also update the count of reactions printed in the output summary to include
surface reactions.
For burner-stabilized flames under blowoff conditions (laminar flame speed less
than burner velocity), the solver can get stuck regridding indefinitely due to
the dependence of the calculated flame speed on the grid spacing (where the
calculated flame speed is artificially high when the grid is coarse).
To obtain solutions more quickly in this case, we check to see if the flame has
moved off of the burner surface (i.e. zero temperature gradient at the burner)
and if so, jump ahead to the non-reacting solution throughout the domain.
Fixes#386
If the domain is narrow with respect to the flame width, there can be
significant temperature gradients at the boundary, which lead to either
incorrect flame speeds or solver failures.
When the 'auto' option to FreeFlame.solve is specified, the solver will now
check the gradients at the ends of the domain after each steady-state solve and
increase the width if necessary.
Fixes#385
Adds a new internal-only option for the pythonX_package variables,
'minimal-default'. This value is set when pythonX_package has not been
configured by the user (i.e., it started as default) and checking for
Cython or NumPy fails, so we can't build the full interface.
If python_package is default and pythonX_package is present (where X is
the same version of Python as python_package), prefer the
pythonX_package options and don't warn quite so much
`ConstDensityThermo::standardConcentration(k)` is now calculated
as `density()/molecularWeight(k)`, rather than the previously
incorrect `molarDensity()`.
Note that this causes a problem for any species where
`molecularWeight(k)=0` (i.e. vacancies). Such species should be
avoided, in this phase model.
For that reason, `sofc-test.xml` is changed so that the oxide bulk
is modeled as an `IdealSolidSolution`
Before bba0d8edf, the vector m_molNumSpecies_new was of a size greater than
m_nsp, with elements m_nsp through the end always filled with zeros. Thus the
check removed here always passed. In bba0d8edf, the vector size was reduced to
be the correct size (m_nsp), so this resulted in this check accessing
unallocated memory, causing the check to fail randomly in the TestKOH_Equil
test. The resulting exception was always caught internally, so the solver wasn't
returning incorrect results, but the non-determinism was leading to unexpected
changes in code coverage reports.
Switch to importing the lib3to2 as a check, which is platform agnostic
and doesn't depend on how 3to2 was installed. Also, take advantage of
the fact that the 3to2 converter recurses by default to avoid spawning
a bunch of subprocesses. Finally, don't depend on the location of the
3to2 script and just use the library directly to do the conversion.
Update and make more consistent the specification of Python package
building. Since SCons can be run by Python 3 now, we cannot assume that
the Python running SCons is Python 2. This changes a bunch of
assumptions in SConstruct about where things should be built or
installed. This commit addresses those assumptions by making the options
for Python 2 and Python 3 symmetric.
If no full or minimal Python interface is being built, copy the minimal
interface into the build directory and use the sys.executable to run it,
so the tests that require CTML or CTI conversion can run.
