Dirichlet to value and Neumann to rate?

[jgostick]

The ambiguity of the neumann boundary condition is causing problems...apparently OpenFOAM calls them fixed_value and fixed_rate. Should we just go with value and rate?

[ma-sadeghi]

I like changing Neumann to rate but Dirichlet is expressive enough.

[jgostick]

I propose changing both so that they match...consistency is good right?

@TomTranter and @magnaou , can you weigh in on this one?

[magnaou]

@jgostick following our yesterday's discussion, I agree.

[TomTranter]

i like value and flux

[TomTranter]

rates can be volumetric

[ma-sadeghi]

@TomTranter But flux is supposed to be per unit area, might be confusing.

[TomTranter]

Isn't that what we want? That's the BC in any 3d fluid mechanics simulation

[ma-sadeghi]

Currently, Neumann applies rate (flux * area).

[TomTranter]

This is frustrating, we need units!!!!

[TomTranter]

We should go with the situation most like an experiment. You control the value, or you control the flow rate. X/m^2.s

[TomTranter]

Anyway - my point was that rate is a little ambiguous. Whatever Neumann is - if we're doing Neumann then we should call it Neumann. If we want to be like other fluid solvers we should accept a flux as a BC and change the calculations slightly if that's not what we actually use.

[ma-sadeghi]

I totally agree. The only concern is that if you want to apply rate/flux to a single pore, definition of the area could get tricky. This does not happen often as we can't apply flux/rate to a single pore in reality. But a really good use case is when dealing with dual networks. Let's say you're generating heat in the gas phase and due to high thermal conductivity of the solid, you assume that all of the generated heat transfers to the solid network. In that case, we might need to apply rate directly, rather than flux.

[TomTranter]

Isn't that more like a source term

[ma-sadeghi]

Yep, could be. But then every rate BC could be treated as a constant source term and vice versa (I guess).

[TomTranter]

I guess we don't necessarily have to conform to continuum CFD conventions. But physically what are we actually defining and solving? Quantity entering boundary pore per unit time? I guess that sounds most like a rate. Neumann is the gradient of the solution but we need to multiply that by the conductivity to get the rate. So if we're actually setting the rate its not strictly Neumann. I think I agree with you then :) Got there in the end

[jgostick]

:-D We are definitely in the wrong by using 'neumann'. Flux would be nice, but the area is a pain to figure out, so we should go with rate. As for changing Dirichlet, we are technically fine here, but I just want the terms to 'match' because I'm ridiculous. Besides, it's what openfoam uses, so I propose changing dirichlet to value.

[jgostick]

we could arguably add 'flux' at some future date if we ever figure out what that means. Flux might be a good term to use for the old 'nemann_group', were you assign a cumulative rate to a group of pores.

[TomTranter]

domain flux for the effective props

[TomTranter]

Something feels wrong about boundary pores altogether... It might make more sense to just have boundary throats that are all connected to one big pore (the super pore or Neumann group) and then define the total rate leaving the super pore. The super pore would span the domain face.

[TomTranter]

Is that essentially how it worked before except we had a bunch of boundary pores in between?

[TomTranter]

It kinda fits more with the flux convention as the important property of the throat is the cross-sectional area

[jgostick]

Trying to fix this presented a stupidly annoying problem: we use 'pore.dirichlet' to indicate the locations where dirichlet conditions are applied, and 'pore.dirichlet_value' to indicate the value at those locations. If we change the name to 'value', then we now have 'pore.value' and 'pore.value_value'.

A fix would be to only have on array called 'pore.value', which is initialized to nans. Then the locations where bcs are set is found using ~sp.isnan. Same would go for pore.rate. Actually, to be super clear, I would say that these arrays should be called 'pore.bc_value' and 'pore.bc_rate'.

[TomTranter]

If our boundaries were individual geometry objects would that help. Like bound_l = op.geometry.boundary(net, (P1,2,3), name=left, value=1.0, rate=None) They could then contain planar checks and other methods. Might want to break out rules of not having overlapping geometries or give them a class of their own.

On Mon, 7 May 2018, 23:28 jgostick, notifications@github.com wrote:

Trying to fix this presented a stupidly annoying problem: we use 'pore.dirichlet' to indicate the locations where dirichlet conditions are applied, and 'pore.dirichlet_value' to indicate the value at those locations. If we change the name to 'value', then we now have 'pore.value' and 'pore.value_value'.

A fix would be to only have on array called 'pore.value', which is initialized to nans. Then the locations where bcs are set is found using ~sp.isnan. Same would go for pore.rate. Actually, to be super clear, I would say that these arrays should be called 'pore.bc_value' and 'pore.bc_rate'.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PMEAL/OpenPNM/issues/862#issuecomment-387273429, or mute the thread https://github.com/notifications/unsubscribe-auth/AGvcRTIrVJXFinuEnyfFlhVbHpNcuOBvks5twRDdgaJpZM4TcYiX .

[jgostick]

very interesting! We also have an issue open about making better use of boundary objects (#839), so this might be an interesting approach.

[jgostick]

This is now done in a PR (#898)

[xu-kai-xu]

I think the boundary condition setting now is nice. The name of value and rate is vivid and explicit. And the name of Dirichlet and Neumann seems too mathematical.

Then, I have another question about the boundary condition. In some numerical simulations, like LBM, periodic boundary condition, elastic boundary condition, and so on. These boundary conditions may deal with the materials, as I understand. I am curious about which boundary condition is used in PNM, e.g., if I set inlet and outlet pressures for a network. What do OpenPNM do with the fluid flowing out of the network? Just ignore it, or put it back to the inlet pores.

Or, my question is wrong. OpenPNM do not have this kind of boundary conditions.

[jgostick]

I don't know about elastic bcs, but periodic would indeed be nice. This requires more than just a BC though, it's requires topological changes to the network, by adding 'stitch' throats. In fact, our oldest open issues on github pertains to how to deal with 'periodic' throats.