-
Notifications
You must be signed in to change notification settings - Fork 6
Improve ReactorNet handling of bulk phase interactions #202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
That's indeed a tricky question.
This makes me think of one of the (currently abandoned) things I had pondered a while ago #61 (especially what was outlined for With respect to #61, my instinct would be to decouple |
Thanks for the reminder of #61. I think resolving this feature using the second approach I described, which would decouple the rate evaluation for each surface from the evaluation of a specific |
Abstract
The handling of surface reactions in the
ReactorNet
framework is mostly focused on catalytic surfaces that only interact with a single bulk (gas) phase, or involve deposition/ablation with an effectively infinite reservoir. Surfaces that define reactions involving net mass transfer between two bulk phases can be defined and mostly work, but they have some rough edges. The goals of this enhancement are:Motivation
Consider the following example, using the input file CaCO3-calcination-surface.yaml.txt (which needs to be renamed due to GitHub's file type limitations) adapted from this Users' Group post:
The issues to be resolved here are:
(1) The need to define 3
ReactorSurface
objects. Currently, aReactorSurface
always "belongs" to a singleReactor
object, and is responsible for determining its own surface species' rates of production and modifying the rates of production for theReactor
that owns it. It cannot modify the rates of species production for other phases/reactors. This approach means that the system of equations includes the surface species three times each. Also, it requires the phases adjacent to each surface always having their state synchronized when the surface rates are evaluated, which will only happen if each reactor has an independentSolution
object, which relates this to #201.(2) The surface reaction rates are not limited by the mass of one of the adjacent bulk phases reaching zero.
Possible Solutions
From an API perspective, I think it would be preferable to simply define the
ReactorSurface
as being adjacent to severalReactor
s, for example:Internally, I'm not quite sure what the best way to implement this change would be.
The least invasive approach would be to try to leave the current structure, where the
ReactorSurface
is managed by one of the bulk phases, but then needs to update components of theRHS
/LHS
arrays that affect other adjacentReactors
. However, this may not be possible becauseReactor::eval
is only provided with its own "local" segment of the overallRHS
/LHS
arrays.Another approach would be to elevate
ReactorSurface
by a level in the evaluation of the equations, where it would be handled directly byReactorNet
. Here,ReactorSurface::eval
would be responsible for computing the governing equations for each surface species, and for storing an array with the net production rates of the bulk phase species for each adjacent bulk phase. These would then be used byReactorXyz::eval
to compute theRHS
/LHS
terms for its bulk phase species.I think either of these approaches require #201 to be resolved first.
I haven't yet thought about how to handle the mass of one of the phases going to zero.
References
This was motivated by the example posted on the Users' Group
The text was updated successfully, but these errors were encountered: