Get effective Arrhenius parameters using SurfaceArrhenius class

[imitrichev]

1. Lattice class is added to create ideal lattice object. The code is written in a manner of IncompressibleSolid (IncompressibleSolid.h). Usage:

Cantera::Lattice* bulk;
std::string name="1.cti";
bulk=new Cantera::Lattice(name, "bulk");
phases.push_back(bulk); //phases is std::vector<Cantera::ThermoPhase*>
//note: add bulk phase to phases before surface (idealInterface), like in cti file.
bulk->setState_TPX(Tcurr,P,Xbulk);
double * b_aconc = new double [bulk->nSpecies()];
bulk->getActivityConcentrations(baconc);
//some more stuff
//use bulk->molarDensity() to access the molar density, the characteristic of lattice species per unit of volume
delete [] b_aconc;
delete bulk;

2. SurfaceArrhenius class is now a derived class, the parent being Arrhenius. Some methods of SurfaceArrhenius class became virtual.
3. Getters for A, beta, E from SurfaceArrhenius class introduced, two of them are overloaded functions accounting for surface coverage modifiers inclusion into effective reaction rate parameters.
   The reason for getters is to give the user the ability of inspection of reaction rate parameters during surface chemistry calculations. This is convinient when user wants to output reaction rate parameters

These commits are not build-breaking: (scons test)

---

*** Testing Summary ***

---

Tests passed: 967
Up-to-date tests skipped: 0
Tests failed: 0

[speth]

Hi, your efforts are certainly appreciated, but I have a few concerns about these additions:

1) Class LatticePhase has a constructor that takes the input file and phase id as arguments, so you can already just write

bulk = new Cantera::LatticePhase("1.cti", "bulk");

or do away with the manual memory management and just write:

Cantera::LatticePhase bulk("1.cti","bulk");

I know the interface is a bit inconsistent here among the different classes, with some having constructors from input file and phase id and others having a wrapper class to provide this, but I think I prefer the former.

2) The classes defined in RxnRates.h all deliberately do not use inheritance or virtual methods. The reason is to avoid the overhead of the virtual function calls, since the methods of these classes are for the most part very short and called very frequently. I don't know that the overhead is actually significant in practice, but there are reasons for the current design.

3) Access to the rate coefficient parameters is already provided through a more general interface to the Reaction objects (via Kinetics::reaction). This implementation has the advantage of working for all Kinetics subclasses and all rate coefficient parameterizations.

[imitrichev]

Thank you! But I cannot see if the Reaction class provides any easy method to obtain effective parameters, e.g., activation energy with account for all coverage dependencies.

// user should cast to InterfaceReaction to get access to coverage_deps
Cantera::InterfaceReaction& some_reaction= dynamic_cast <Cantera::InterfaceReaction& > (*(surf->reaction(reaction_number)));
// Clean (unmodified) parameters are returned when using e.g.
std::cout << some_reaction.rate.activationEnergy_R() << std::endl;

As I understand, one should iterate over some_reaction.coverage_deps (it is std::map<std::string, CoverageDependency> coverage_deps), get a, m and E fields from CoverageDependency object for each record, get the corresponding species std::string coverages theta, and consistently multiply each other to calculate the effective parameters (e.g., effective activation energy) of this surface reaction. SurfaceArrhenius already does this task in function update_C, and this class would be useful to provide an ability to get effective parameters: it can be easily done somewhere in the code using m_acov, m_ecov, m_mcov from SurfaceArrhenius class (I also suppose to include m_acov and m_mcov into preexponential parametrization since they do not have a form of temperature exponent T^... - they do not depend on temperature)
As m_acov, m_ecov, m_mcov are protected, one should implement "getter" functions in SurfaceArrhenius class, I think.

[speth]

Thanks for the clarification. I can see some utility in having access to the effective rate coefficient parameters for class SurfaceArrhenius. If you want to provide a patch that just adds those methods (and the wrappers to access through InterfaceKinetics), then I think that would be fine.

[imitrichev]

Fixed it! Is it appropriate now?

[speth]

I think this is pretty close. A few more minor suggestions:

• I think that SurfaceArrhenius should not inherit from Arrhenius. As written in this PR, SurfaceArrhenius has member variables m_b, m_E, etc. which shadow the members ofArrhenius`, which is a bit strange.
• I think the new methods of InterfaceKinetics should not have the "get" prefix, as that is generally only used for methods which fill in an array that's passed as an argument, e.g. getFwdRateConstants(double* kfwd) rather than methods that return a value.
• I don't think there's any reason to add the unused method updateLog
• SurfaceArrhenius::activationEnergy_R should not be virtual
• Don't rename the argument to Arrhenius::update_C

[speth]

Oh, and also the new methods should have docstrings.

[imitrichev]

The field m_logA of SurfaceArrhenius is now not used anywhere. Should it be deleted?

[speth]

Yes, it can be removed.

[imitrichev]

I've done it. Anything else?