* differentiated Valve::setValveCoeff from PressureController::setPressureCoeff
and introduced MassFlowController::setMassFlowCoeff for consistency.
* introduced FlowDevice::setTimeFunction and FlowDevice::setPressureFunction to
differentiate time-dependent and pressure-dependent functions.
* introduced arbitrary pressure dependence for PressureController
* deprecated FlowDevice::setFunction which is replaced by time and pressure
specific functions.
* introduced properties Valve.valve_coeff / PressureController.pressure_coeff /
MassFlowController.mass_flow_coeff in Cython interface and deprecated
Valve.set_pressure_coeff / PressureController.set_pressure_coeff
* deprecated corresponding function calls in clib interface
* deprecate FlowDevice.setParameters (which was only used by MATLAB interface)
* add deprecation warning for int ReactorBase::type() (to be changed after Cantera 2.5)
* introduce temporary std::string ReactorBase::typeStr() (to be renamed after Cantera 2.5)
* deprecate all functions using the old call and introduce associated temporary functions
The general intent here was to enable calculating reaction enthalpies in the
Matlab toolbox, as part of the li-ion battery simulations in PR #563.
This required several changes:
- Create getDeltaEnthalpies.m in Matlab toolbox/@Kinetics, as well as similar
methods for Gibbs free energy and entropy of reaction
- Add kin_getDelta to kineticsmethods.cpp.
- Add getPartialMolarEnthalpies to metalPhase class (it returns all zeros).
Note that similar methods are not enabled for the corresponding
'Standard State' methods, for the time being. Mainly because it is
difficult for me to envision a significant use case, but also because of
some lingering confusion between 'standard' and 'reference' states in
Cantera's codebase.
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.
