Open ischoegl opened 5 years ago
I agree that there is a bit of redundancy here that would be nice to get rid of, but there are some differences between the two that need to be considered.
First, the problem solved by InterfaceKinetics
, using either the advanceCoverages
or solvePseudoSteadyStateProblem
methods, assumes that the state of the other participating phases (e.g. the gas phase) is constant, while in the ReactorNet
approach, the state of these phases is assumed to vary. Currently, I think that setting chemistry to disabled for a reactor will only affect the gas phase reactions, with surface reactions still changing gas phase concentrations, and in any case, the system of equations will still contain all of the gas phase species, which is inefficient if you're only trying to solve for the surface species.
Second, the pseudo-steady state solver available for the surface-only problem is quite different from anything we have available for the general reactor network. However, "different" may mostly mean broken in this case (see Cantera/cantera#609).
@speth ... thanks for your response. It's been a while since I wrote this question, but the main point of my inquiry was that InterfaceKinetics
goes against the philosophy of some of the other implementations within the 0D ReactorNet
approaches. This came up in the context of Cantera/cantera#694.
Regarding your first comment: a Surface
attached to a Reservoir
would be computationally as efficient as advanceCoverages
(I haven't checked: this may or may not be possible at the moment.) Regarding the pseudo-steady state solver: this would imho benefit any other 0D scenario?
Conceptually, I can see how Reservoir
+ Surface
corresponds to the problem solved by InterfaceKinetics.advance_coverages
, but it's not actually implemented that way currently -- I don't think that any equations will be solved for the surface species if you add a Surface
to a Reservoir
.
And yes, the pseudo-steady state solver would be useful if it worked reliably, but it doesn't seem to do that currently. I also wonder whether that solver could just be replaced by the one used for 1D problems.
Yes - Surface
objects currently cannot stand by themselves as they add their species list to an existing Reactor
, which imho is quite limiting.
@speth / @bryanwweber ... could you please move this over to Cantera/enhancements?
@bryanwweber ... could you add a question / feature request tag to this issue? Thanks!
Reopening based on recent discussion in #202.
Cantera version
2.5.0a3
Expected Behavior
A single approach for solving surface problems in the context of zero-dimensional simulations.
Actual Behavior
There appear to be two distinct approaches to simulate surface kinetics problems.
InterfaceKinetics
Reactor
+ReactorSurface
object in a reactor networkadvance_coverages
vsadvance
).Proposal
It is conceivable to merge the approaches by introducing something along the lines of
Example 1:
diamond_cvd.py
Example 2:
surf_pfr.py
There are obviously other scenarios, e.g. edges / triple phase boundaries.
The steps to allow for this would require some changes of
ReactorBase
-derived classes, but would eliminate redundancies in the long run.An advantage of this approach would be that only one time integration approach needs to be maintained. Further, any future serialization would use the same framework.