The "catching polymorphic type" warnings appear during compilation with GCC 8:
src/base/global.cpp: In function ‘void Cantera::setLogger(Cantera::Logger*)’:
src/base/global.cpp:28:19: warning: catching polymorphic type ‘class std::bad_alloc’ by value [-Wcatch-value=]
} catch (std::bad_alloc) {
^~~~~~~~~
src/equil/vcs_MultiPhaseEquil.cpp: In member function ‘int Cantera::vcs_MultiPhaseEquil::equilibrate_HP(doublereal, int, double, double, int, int, doublereal, int, int)’:
src/equil/vcs_MultiPhaseEquil.cpp:228:31: warning: catching polymorphic type ‘class Cantera::CanteraError’ by value [-Wcatch-value=]
} catch (CanteraError err) {
^~~
src/equil/vcs_MultiPhaseEquil.cpp: In member function ‘int Cantera::vcs_MultiPhaseEquil::equilibrate_SP(doublereal, double, double, int, int, doublereal, int, int)’:
src/equil/vcs_MultiPhaseEquil.cpp:354:31: warning: catching polymorphic type ‘class Cantera::CanteraError’ by value [-Wcatch-value=]
} catch (CanteraError err) {
^~~
This commit fix this warnings via caught by reference.
Saved element potentials are only valid at equilibrium, and may not be a good
guess for calls to equilibrate() after the state has changed.
By always using the estimation method for the element potentials at the start of
the ChemEquil algorithm, the results of equilibrate() are repeatable, and do not
depend on the results of previous calls to equilibrate().
Resolves#524
Use the 'loglevel' argument to the 'equilibrate' function to set the logging
level of the ChemEquil (element potential) solver, instead of relying on the
undocumented, static 'ChemEquil_print_lvl' variable which can only be set from
the C++ interface.
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.
The new class is named MultiSpeciesThermo, so that (eventually) the name
SpeciesThermo can be used for the single-species class SpeciesThermoInterpType.
Currently, trivial wrappers for classes named SpeciesThermo and
GeneralSpeciesThermo to maintain backwards compatibiity for Cantera 2.3.
The lack of space between adjacent fields would cause test failures when
comparing output files when using some versions of MinGW (due to 3-digit
exponents).
