A very small change that allows the user to set the initial location of the flame. The original hard-coded values for "locs" are retained as the default, but the user can now modify locs.
The previous formulation will only consider a rection as electrochemical
if a beta value is supplied for that reaction *and* the reaction is an
'edge_reaction.' This is problematic for two reasons: (1) many/most
charge-transfer reactions of interest occur at two-phase boundaries (see,
for example, Li-ion batteries and PEM fuel cells), not the three-phase-
boundary-like edges (which are most relevant for SOFCs). (2) determining
whether a reaction is electrochemical or not should not rely at all upon
user input - the program itself should check to see whether charge is
transferred between phases, and the appropriate steps should be taken
during rate-of-progress calcuations.
This commit addresses the former issue. Currently, if a charge-transfer
reaction is written as a surface_reaction, the code does not apply the
voltage correction to the forward rate. By default, then, the entire
voltage correction is applied to the reverse reaction, which is the same
as setting beta = 0; not a good 'default' behavior (beta = 0.5 is a more
appropriate default). With this change, surface reactions can now be
supplied with a beta value in cti or xml formats, and will be recognized
as a charge transfer reaction.
Longer term, it would be better to change the constructor routines such
that charge transfer is automatically detected and handled, rather than
relying upon user-specified flags.
The definitions of p0, Tmin, and Tmax were circular -- they queried the
STITbyPDSS object which just referenced the same PDSS_IonsFromNeutral
object. Instead, pull these properties from the associated "neutral molecule"
phase.
The overrides of setTemperature and temperature were unnecessary and likely to
cause problems.
Cleaning up `RedlichKwongMFTP:pressure()` and removing `m_Pcurrent` as a cached
value in `RedlichKwongMFTP` and `MixtureFugacityTP`. The stored value was only
ever called in one location `RedlichKwongMFTP:getPartialMolarVolumes()`, and
the function call it replaced (`RedlichKwongMFTP:pressure()`) is not all that
involved.
Exact floating point equality can be assured only in the case where the species
are added in the same order, since this affects summations involved in
calculating the mixture molecular weight. This resulted in test failures with
certain versions of the Intel compiler.
Resolves#433.
If the "a" coefficients for all species were temperature independent, the array
containing "a" at the current temperature was never being populated. Fixes a
regression introduced in 19c17d1.
The 'install' and 'test' targets had some undeclared dependencies on the 'build'
target, such that running 'scons install' or 'scons test' without having first
run 'scons build' would result in incomplete installation or test failures,
respectively.
Fixes#432.
The reference pressure (p0) must be species-specific, since for certain PDSS
classes (e.g. PDSS_Water) p0 is a function of temperature, while for other
classes (PDSS_ConstVol) it is a constant.
VPSSMgr_Water_ConstVol further assumed that the reference pressure for all
species was 1 atm, ignoring the setting in the PDSS object. Fixing this changed
test results for HMW_test_1 and HMW_test_3.
Added a test that specifically compares VPSSMgr_Water_ConstVol with
VPSSMgr_General.
