How to deal with boundary pores?

[ma-sadeghi]

This issue is reserved for thoughts and ideas on how to deal with boundary pores. Let me back up what we've already discussed so far. Feel free to comment and suggest new ideas so we can come up with a conclusion and deal with boundary pores once and for all!

Annoying Boundary class

One of the annoying issues with Boundary geometry class is that we necessarily need to create a physics object associated with that Boundary class. Needless to say, that neither Boundary nor the associated physics class do anything special, but just need to be there, cluttering the run script.

No special Boundary treatment?

We wanted to get rid of the Boundary class, and instead make conductance models "smart" enough that they can "infer" boundary pores, hence setting their conductance to infinity. That option is still on the table, and in my opinion, is the preferred solution.

Special geometry/physics classes for boundary pores

The other option is to force user to use a special Boundary class that we provide, so we can inform the conductance models that a pore is a boundary pore via a surrogate property. For instance, net["pore.area"] == 0 triggers the conductance models to assume a boundary pore. The downside of this approach is that we need to create a separate physics for the Boundary geometry class.

[xu-kai-xu]

hi, @ma-sadeghi, @jgostick, I am curious about why should we use the boundary pores in pnm, when it must be considered and when we may ignore it without influencing the simulation results. From your discussions above, I found that boundary pores need to be considered when the conductance model is used. I guess this means all the simulation of flow and diffusion process should include boundary pores, because of the hydraulic conductance and diffusion conductance.

Another question is similar to this. When simulating a one-phase flow process, the conduit is need to calculate. It consists of two half pores connected by a throat. The hydraulic conductance is calculated based on the conduit. So, when counting the conduits in pnm, pores are not at the boundary is with no problem. But for pores at the boundary, only half of them is used for the conduit, the other half seems useless. Can the boundary pore treatment fix this situation? Thanks.

[ma-sadeghi]

@xu-kai-xu That's a good question. There are a couple of points:

Ideally, adding boundary pores should not change the simulation results. So one might ask: why include them in the first place? In my opinion, they should be avoided if possible because they just add complexity to your code by adding extra objects, namely a geometry and a physics dedicated to the boundary pores.

In principle, they might make your simulation marginally more accurate. Here's a depiction of what I mean:

On the right, we don't have any boundary pores, so if you run Fickian diffusion algorithm, essentially you're running the algorithm within the red box, so you're essentially neglecting the outer regions of your "surface" pores (let's call real boundary pores, i.e. real pores that happen to be on the boundary of the network as "surface" to not confuse them with artificial boundary pores).

On the left, we've added boundary pores and therefore, the if we run the same simulation, we're essentially running it on a domain that's slightly larger than the actual physical domain (red box), but that's not a problem because we define properties of boundary pores such that they impose 0 resistance (or infinite conductance), so essentially they won't contribute to any loss, and consequently, your simulation will be run on the domain as shown by the green box, which is probably the closest to the actual physical domain.

The advantage that I explained above is the only one that I can think of for adding boundary pores, which in my opinion, is not worth the extra added complexity.

So, to answer your question, you don't necessarily need to have boundary pores. I'd recommend that you never add them unless you really have to.

[taylrcawte]

From #1668

To deal with the extra boundary pores added by the SNOW algorithm we did the following:

1. extracted network using SNOW and setting boundary labels to "top"
2. stored extracted network in openpnm generic network
3. trimmed added boundary pores (from snow)
4. created imported geometry object for network
5. used the pore coordinates to determine which pores were "touching" the surface of the network (denoted as face pores)
6. added new boundary pores to these face pores
7. created new geometry object for these boundary pores

The script used to generate and run the network can be found here:

https://gist.github.com/taylrcawte/1c61d80e640a649d19f5422a7b92da9c

[jgostick]

This issue is actually not important anymore since the cone_and_cylinder geometry can deal with short but wide pores (i.e. boundary pores) without issue.