Disable generation of globalIDs in GEOS for fracture meshes

[ryar9534]

We have seen that using GEOS to generate global IDs in examples where the mesh is fractured/split (and thus has collocated nodes) is unreliable as vtk will give the same global id to collocated nodes. Here I think I have simply returned an error in these cases so it is clear what is happening.

We could also just leave the code as is, as the code will likely catch the duplicated globalIDs, but if we like this we can merge it. Note also that even if GEOS uses vtk to assign global IDs, we still use the collocated nodes field from the vtk mesh for the fault to define the connectivity of the fracture to the matrix. At that point we could be using different numbering schemes which could lead to some very wacky stuff.

[CusiniM]

maybe pass it an actual bool, no?

[rrsettgast]

@ryar9534 is vtk or GEOS generating the globalIDs?

[ryar9534]

@ryar9534 is vtk or GEOS generating the globalIDs?

I believe its vtk under the hood, I think its happening here

GEOS/src/coreComponents/mesh/generators/VTKUtilities.cpp

Line 202 in 5596189

generateGlobalIDs( vtkSmartPointer< vtkDataSet > mesh )

[rrsettgast]

@ryar9534 is vtk or GEOS generating the globalIDs?

I believe its vtk under the hood, I think its happening here

GEOS/src/coreComponents/mesh/generators/VTKUtilities.cpp

Line 202 in 5596189

generateGlobalIDs( vtkSmartPointer< vtkDataSet > mesh )

So VTK is checking coordinates and assuming colocated nodes are the same? Can't we just offset the nodes normal to the fault/fracture?

[ryar9534]

@ryar9534 is vtk or GEOS generating the globalIDs?

I believe its vtk under the hood, I think its happening here

GEOS/src/coreComponents/mesh/generators/VTKUtilities.cpp

Line 202 in 5596189

generateGlobalIDs( vtkSmartPointer< vtkDataSet > mesh )

So VTK is checking coordinates and assuming colocated nodes are the same? Can't we just offset the nodes normal to the fault/fracture?

I suppose you could, I think thats just not the workflow @TotoGaz has been developing

[TotoGaz]

So VTK is checking coordinates and assuming colocated nodes are the same?

yes https://vtk.org/doc/nightly/html/classvtkGenerateGlobalIds.html

Can't we just offset the nodes normal to the fault/fracture?
I suppose you could, I think thats just not the workflow @TotoGaz has been developing

Fractures use the global node ids to refer to matrix nodes.
Having another process renumber the nodes is bound to fail.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.74%. Comparing base (c74702a) to head (6f57cd8).
Report is 89 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3200   +/-   ##
========================================
  Coverage    55.74%   55.74%           
========================================
  Files         1038     1038           
  Lines        88470    88471    +1     
========================================
+ Hits         49320    49321    +1     
  Misses       39150    39150           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rrsettgast]

So VTK is checking coordinates and assuming colocated nodes are the same?

yes https://vtk.org/doc/nightly/html/classvtkGenerateGlobalIds.html

Can't we just offset the nodes normal to the fault/fracture?
I suppose you could, I think thats just not the workflow @TotoGaz has been developing

Fractures use the global node ids to refer to matrix nodes. Having another process renumber the nodes is bound to fail.

Does a call to generateGlobalIDs( vtkSmartPointer< vtkDataSet > mesh ) properly assign globalID to nodes?
When does it fail? Why does it fail?

[ryar9534]

So VTK is checking coordinates and assuming colocated nodes are the same?

yes https://vtk.org/doc/nightly/html/classvtkGenerateGlobalIds.html

Can't we just offset the nodes normal to the fault/fracture?
I suppose you could, I think thats just not the workflow @TotoGaz has been developing

Fractures use the global node ids to refer to matrix nodes. Having another process renumber the nodes is bound to fail.

Does a call to generateGlobalIDs( vtkSmartPointer< vtkDataSet > mesh ) properly assign globalID to nodes? When does it fail? Why does it fail?

I'll try and answer this to take the load off @TotoGaz. For 'split' meshes with faults/fractures, we have been assuming the 'matrix' mesh (so the mesh of the 3D solid), has multiple nodes which are co-located on the fault. In this case assigning node global ids using vtk within geos will not work, as it will assign the same global ID to collocated nodes. Even if we assume that this was not the case, i.e. for whatever reason the call to vtk within geos properly assigned unique global IDs to collocated nodes, there could still be an issue. In particular, when we import the fracture we still make use of a 'collocated_nodes' field defined on the nodes of the fracture mesh. This field gives the global IDs of the 'matrix' nodes which are collocated with that node in the fracture. Even if the call to vtk gave valid (unique) global IDs to the matrix nodes, this ordering may not be the same as how 'collocated_nodes' was defined. I believe this is what Thomas was referring to in his comment. So it seems to me like the safest option (at least for now) is to throw an error if we attempt to create new globalIDs for a vtk mesh which includes a fault (indicated by the fractures variable being non-empty in the above changes). Hopefully that is (a) correct according to @TotoGaz and (b) answers your question @rrsettgast. Im happy to chat more whenever though!