Caused most Matlab flame simulations to fail, e.g. those using
CounterFlowDiffusionFlame.m or flame.m. Fixes regression introduced in c1067aa.
Fixes#554
The CounterFlowDiffusionFlame (CFDF) code is able to perform more general cases
of npflame_init for multiple species fuel and oxidizer streams. The
stoichiometric mixture fraction in the CFDF code uses the Bilger definition of
mixture fraction, using the conservation of elements C, H, and O. This method is
used in the python module, but not the MATLAB npflame_init function.
Also, the CFDF code uses the fuel stream density to calculate the fuel stream
velocity and the oxidizer stream density to calculate the oxidizer stream
velocity, where as the npflame_init code uses the fuel density for both velocity
calculations.
The elementMassFraction code is a MATLAB version of the python function:
elemental_mass_fraction, which is needed to run the CFDF code.
Update the diffflame.m example to use the more general CFDF function since the
input parameters are different than the npflame_init function. This example is
the same as the diffusion_flame.py sample in the Python module.
This function was actually being directed into 'thermoget' and calling the
'newFromXML' method (on a non-existent XML tree) instead of calling the 'del'
method.
At some point (after version 2014b), Matlab started passing an additional
argument to 'display', which broke the logic for setting the default
threshold. This caused all composition data to be excluded from the report shown
by typing the name of the phase object.
Because normalizing the species coverages leads to incorrect Jacobian
calculations, it is sometimes necessary to not normalize the coverages.
As for bulk species mass/mole fractions, this option is currently only
available when passing the coverages as a vector (i.e., not available
for string identifiers).
The value of this argument has almost no effect on the integrator, and
frequently confuses users since the ReactorNet can end up at a time either
greater or less than the specified time. By removing this argument, the
distinction betwen step() and advance(t) becomes much more clear.
Without these functions, it was impossible to use these classes
without leaking memory. Even with these functions, the memory is
released only when these functions are explicitly called, as
old-style Matlab classes have no notion of a destructor.
Fixes#252.
