GEOS-DEV / GEOS

GEOS Simulation Framework
GNU Lesser General Public License v2.1
206 stars 83 forks source link

Improvement to TPFA #2162

Open karimifard opened 1 year ago

karimifard commented 1 year ago

The discretization must provide accurate two-point flux approximation for PEBI and orthogonal grids. Provide approximation for mesh elements with nonplanar faces. Remain compatible with existing explicit and embedded discrete fracture representation. Approximate use of full tensor permeability for TPFA.

List of features/capabilities:

MPFA Cleaning:

Inputs (1/2):

Computational geometry tools:

Discretization TPFA

Inputs (2/2):

Import of TPFA connectivities. (long term objective)

CusiniM commented 1 year ago

EDIT: merged into main issue description.

old comment I propose the following path forward: Step 1: stencil clean up and import of collocation points. - [ ] PR: stencil clean up. Remove MPFA stencil and revisit all variables in stencil objects to make sure they are appropriate for the new goals. - [ ] PR: import of collocation points. Seems to be urgent so I think it can be done independently to have a working capability soon that can then be adapted to the cleaned up stencils. Step 2: Full tensor permeability and non planar faces. - [ ] PR: implement needed computational geometry tools to handle a full tensor permeability and non planar faces and add proper unit tests for them. - [ ] PR: modify permeability to be a full tensor and refactor stencil's weights computations + add unit and integrated tests for it. Step 3: import of tpfa connectivities. - [ ] PR: import of tpfa connectivities. - [ ] PR: graph based ghosting strategy. - [ ] vtk upgrade (possibly multiple PRs)
CusiniM commented 1 year ago

Btw, before starting on all this it would be better to merge this PR https://github.com/GEOSX/GEOSX/pull/1925

TotoGaz commented 1 year ago

@CusiniM Step 3 should be merged with step 2, since it has a direct impact on the computation of the stencil weights.

Hmm, I'm not 100% sure because we're reaching a point where the way we read the VTK is really decoupled from what we do with the digested data. Not to say that both ways are independent, nor that both ways are equally "easy", but depending on the resources and the priorities, we may want to willingly split those tasks.

CusiniM commented 1 year ago

@CusiniM Step 3 should be merged with step 2, since it has a direct impact on the computation of the stencil weights.

Hmm, I'm not 100% sure because we're reaching a point where the way we read the VTK is really decoupled from what we do with the digested data. Not to say that both ways are independent, nor that both ways are equally "easy", but depending on the resources and the priorities, we may want to willingly split those tasks.

ahah, I have modified my comment after Nicola's one so 2 and 3 are not the same thing anymore and I have already merged my origin point 2 and 3 into a single one.

TotoGaz commented 1 year ago

When you're using the step, it implicitly means that there's an order. Is it what you mean? To which extent is this the case?

CusiniM commented 1 year ago

When you're using the step, it implicitly means that there's an order. Is it what you mean? To which extent is this the case?

I have deleted nicola's comment to avoid confusion.

Yeah, I wrote it with the idea of doing these things in sequence. IMO the only step that is kind of independent is the vtk upgrade which, as you said, could be done in parallel and kind of live its own life.

karimifard commented 1 year ago

We may also need a backup plan for highly distorted elements.