Dualism of InterfaceKinetics vs Reactor Networks (ReactorSurface)?

[ischoegl]

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 network
• Time integration is handled by two completely separate functions (advance_coverages vs advance).

Proposal

It is conceivable to merge the approaches by introducing something along the lines of

Example 1: diamond_cvd.py

g, dbulk = ct.import_phases('diamond.cti', ['gas', 'diamond'])
d = ct.Interface('diamond.cti', 'diamond_100')
gas = ct.Reservoir(g)
solid = ct.Reactor(dbulk)
surf = ct.Surface(d, [gas, solid])

sim = ct.ReactorNet([solid, surf])
sim.advance(some_end_time)

Example 2: surf_pfr.py

gas = ct.Solution('methane_pox_on_pt.cti', gas)
surf = ct.Interface('methane_pox_on_pt.cti', 'Pt_surf')
reactor = ct.IdealGasReactor(gas)
surf = ct.Surface(d, [reactor])
# skipping inlet/outlet plumbing for brevity

sim = ct.ReactorNet([reactor, surf])
sim.advance_to_steady_state()

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.

[speth]

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).

[ischoegl]

@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?

[speth]

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.

[ischoegl]

Yes - Surface objects currently cannot stand by themselves as they add their species list to an existing Reactor, which imho is quite limiting.

[ischoegl]

Reopening based on recent discussion in #202.