* To allow setting properties on the upstream classes, __setattr__ is
implemented and checks whether the attribute is defined on this
class. This requires setting the phase instance directly into the
__dict__ attribute to avoid a recursion error.
* Class inheritance is not used here because it is not easy to set
attributes on the super class. By design, super() does not allow
setting properties, only getting. Furthermore, since the base
PureFluid class is defined in Cython, the attributes of that class
cannot be set by subclasses at all, again by design.
* The PureFluid class implemented here does not inherit from the
Solution class implemented here because eventually this Solution class
will include methods and properties related to kinetics and transport,
which are not implemented for PureFluid. The base PureFluid class is a
subclass of ThermoPhase only, whereas the base Solution class is a
subclass of ThermoPhase, Kinetics, and Transport.
* To reflect the distinction between Solution and ThermoPhase, the
template variables are renamed.
* Several methods of the PureFluid are getters only, despite having
three properties. These attributes are fixed here. TPQ is the only
three-property attribute with a setter.
* Setter methods now raise a CanteraError if the unit conversion to base
units fails due to an AttributeError.
These examples use the units module to implement the existing examples,
but demonstrate how alternative units can be used for the input and
output quantities.
These differ specifically in the case of sticking reactions, where the
rate coefficient has units like m^3/kmol/s, depending on the reactant
orders while the sticking coefficient itself is dimensionless.
The forward rate constants for falloff and chemically activated reactions
already incorporate the third-body dependency, so the units should only
reflect the explicit reactants. This was being compensated for when
setting the units of the high/low pressure rate expressions, so it did
not affect any results.
Previously, accessing an ExtensibleRate object from a Reaction object
would create a new wrapper object rather than providing access to the
"original" object that is used by the ReactionRateDelegator, and this
wrapper object would not behave the same as the original object except
for methods that passed through via the Delegator.
Now, we return the underlying object, ensuring consistency. This requires
more complex memory management because the ExtensibleRate/Delegator pair
form a reference cycle that can be attached to other objects either from
the C++ or the Python side.
