Cantera
2.3.0
|
Classes | |
class | ImplicitSurfChem |
Advances the surface coverages of the associated set of SurfacePhase objects in time. More... | |
class | Kinetics |
Public interface for kinetics managers. More... | |
Functions | |
bool | installReactionArrays (const XML_Node &p, Kinetics &kin, std::string default_phase, bool check_for_duplicates=false) |
Install information about reactions into the kinetics object, kin. More... | |
bool | importKinetics (const XML_Node &phase, std::vector< ThermoPhase * > th, Kinetics *kin) |
Import a reaction mechanism for a phase or an interface. More... | |
double | checkDuplicateStoich (std::map< int, double > &r1, std::map< int, double > &r2) const |
Check whether r1 and r2 represent duplicate stoichiometries This function returns a ratio if two reactions are duplicates of one another, and 0.0 otherwise. More... | |
A kinetics manager is a C++ class that implements a kinetics model; a kinetics model is a set of mathematical equation describing how various kinetic quantities are to be computed – reaction rates, species production rates, etc. Many different kinetics models might be defined to handle different types of kinetic processes. For example, one kinetics model might use expressions valid for elementary reactions in ideal gas mixtures. It might, for example, require the reaction orders to be integral and equal to the forward stoichiometric coefficients, require that each reaction be reversible with a reverse rate satisfying detailed balance, include pressure-dependent unimolecular reactions, etc. Another kinetics model might be designed for heterogeneous chemistry at interfaces, and might allow empirical reaction orders, coverage-dependent activation energies, irreversible reactions, and include effects of potential differences across the interface on reaction rates.
A kinetics manager implements a kinetics model. Since the model equations may be complex and expensive to evaluate, a kinetics manager may adopt various strategies to 'manage' the computation and evaluate the expressions efficiently. For example, if there are rate coefficients or other quantities that depend only on temperature, a manager class may choose to store these quantities internally, and re-evaluate them only when the temperature has actually changed. Or a manager designed for use with reaction mechanisms with a few repeated activation energies might precompute the terms \( exp(-E/RT) \), instead of evaluating the exponential repeatedly for each reaction. There are many other possible 'management styles', each of which might be better suited to some reaction mechanisms than others.
But however a manager structures the internal computation, the tasks the manager class must perform are, for the most part, the same. It must be able to compute reaction rates, species production rates, equilibrium constants, etc. Therefore, all kinetics manager classes should have a common set of public methods, but differ in how they implement these methods.
A kinetics manager computes reaction rates of progress, species production rates, equilibrium constants, and similar quantities for a reaction mechanism. All kinetics manager classes derive from class Kinetics, which defines a common public interface for all kinetics managers. Each derived class overloads the virtual methods of Kinetics to implement a particular kinetics model.
For example, class GasKinetics implements reaction rate expressions appropriate for homogeneous reactions in ideal gas mixtures, and class InterfaceKinetics implements expressions appropriate for heterogeneous mechanisms at interfaces, including how to handle reactions involving charged species of phases with different electric potentials — something that class GasKinetics doesn't deal with at all.
Many of the methods of class Kinetics write into arrays the values of some quantity for each species, for example the net production rate. These methods always write the results into flat arrays, ordered by phase in the order the phase was added, and within a phase in the order the species were added to the phase (which is the same ordering as in the input file). Example: suppose a heterogeneous mechanism involves three phases – a bulk phase 'a', another bulk phase 'b', and the surface phase 'a:b' at the a/b interface. Phase 'a' contains 12 species, phase 'b' contains 3, and at the interface there are 5 adsorbed species defined in phase 'a:b'. Then methods like getNetProductionRates(doublereal* net) will write and output array of length 20, beginning at the location pointed to by 'net'. The first 12 values will be the net production rates for all 12 species of phase 'a' (even if some do not participate in the reactions), the next 3 will be for phase 'b', and finally the net production rates for the surface species will occupy the last 5 locations.
bool installReactionArrays | ( | const XML_Node & | p, |
Kinetics & | kin, | ||
std::string | default_phase, | ||
bool | check_for_duplicates = false |
||
) |
Install information about reactions into the kinetics object, kin.
At this point, parent usually refers to the phase XML element. One of the children of this element is reactionArray, the element which determines where in the XML file to look up the reaction rate data.
p | parent XML phase element |
kin | Kinetics object to install reactions into |
default_phase | The default_phase is the default phase to assume when looking up species. |
check_for_duplicates | Check for reactions with exactly the same reactants and products. |
Definition at line 29 of file importKinetics.cpp.
References Kinetics::addReaction(), XML_Node::attrib(), Kinetics::checkDuplicates(), XML_Node::child(), Cantera::get_XML_Node(), XML_Node::getChildren(), XML_Node::hasChild(), Cantera::newReaction(), Cantera::npos, XML_Node::root(), Kinetics::skipUndeclaredSpecies(), and Kinetics::skipUndeclaredThirdBodies().
bool importKinetics | ( | const XML_Node & | phase, |
std::vector< ThermoPhase * > | th, | ||
Kinetics * | kin | ||
) |
Import a reaction mechanism for a phase or an interface.
This routine will import a reaction mechanism into a kinetics object. The reaction mechanism may either be homogeneous or heterogeneous, involving multiple ThermoPhase objects. The hosting phase should be included as the first argument. For example, if phase I is an interface phase between bulk phases A and B. Then, the XML_Node for phase I should be the first argument. The vector of ThermoPhase objects should consist of pointers to phases I, A, and B.
phase | This is an XML node containing a description of the owning phase for the kinetics object. Within the phase is a XML element called reactionArray containing the location of the description of the reactions that make up the kinetics object. Also within the phase is an XML element called phaseArray containing a listing of other phases that participate in the kinetics mechanism. |
th | This is a list of ThermoPhase pointers which must include all of the phases that participate in the kinetics operator. All of the phases must have already been initialized and formed within Cantera. However, their pointers should not have been added to the Kinetics object; this addition is carried out here. Additional phases may be include in the list; these have no effect. |
kin | This is a pointer to a kinetics manager class that will be initialized with the kinetics mechanism. Inherited Kinetics classes should be used here. |
Definition at line 129 of file importKinetics.cpp.
References XML_Node::hasChild(), and XML_Node::parent().
Referenced by Cantera::buildSolutionFromXML(), Interface::Interface(), and KineticsFactory::newKinetics().
|
protected |
Check whether r1
and r2
represent duplicate stoichiometries This function returns a ratio if two reactions are duplicates of one another, and 0.0 otherwise.
r1
and r2
are maps of species key to stoichiometric coefficient, one for each reaction, where the species key is 1+k
for reactants and -1-k
for products and k
is the species index.
Definition at line 239 of file Kinetics.cpp.