-
Notifications
You must be signed in to change notification settings - Fork 90
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
feat: Implement EDFM loading from VTK #3510
base: develop
Are you sure you want to change the base?
Conversation
Co-authored-by: Pavel Tomin <ptls@PW0BMYGN>
…GEOS-DEV/GEOS into Feature/ouassim/edfm_loader_new
@@ -75,7 +75,7 @@ EmbeddedSurfaceGenerator::EmbeddedSurfaceGenerator( const string & name, | |||
|
|||
registerWrapper( viewKeyStruct::targetObjectsNameString(), &m_targetObjectsName ). | |||
setRTTypeName( rtTypes::CustomTypes::groupNameRefArray ). | |||
setInputFlag( dataRepository::InputFlags::OPTIONAL ). | |||
setInputFlag( dataRepository::InputFlags::REQUIRED ). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CusiniM why this would be required when vtk input is used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not need the EmbeddedSurfaceGenerator at all when vtk is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh right yes, that makes sense then
<DataArray type="Int64" Name="connectivity" format="ascii" RangeMin="0" RangeMax="47"> | ||
0 1 5 4 16 17 21 20 | ||
1 2 6 5 17 18 22 21 | ||
2 3 7 6 18 19 23 22 | ||
4 5 9 8 20 21 25 24 | ||
5 6 10 9 21 22 26 25 | ||
6 7 11 10 22 23 27 26 | ||
8 9 13 12 24 25 29 28 | ||
9 10 14 13 25 26 30 29 | ||
10 11 15 14 26 27 31 30 | ||
16 17 21 20 32 33 37 36 | ||
17 18 22 21 33 34 38 37 | ||
18 19 23 22 34 35 39 38 | ||
20 21 25 24 36 37 41 40 | ||
21 22 26 25 37 38 42 41 | ||
22 23 27 26 38 39 43 42 | ||
24 25 29 28 40 41 45 44 | ||
25 26 30 29 41 42 46 45 | ||
26 27 31 30 42 43 47 46 | ||
</DataArray> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this ever used? I don't think we use this field. Or is it needed by vtk?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is used internally by VTK to map fracture patches to their nodes. I use it here VtkEmbeddedSurfaceBlockUtilities.cpp
ArrayOfArrays< localIndex > elem2dToNodes( numEdfmFracs );
for( vtkIdType i = 0; i < numEdfmFracs; ++i )
{
auto const val = grid->GetCell( i )->GetPointIds();
elem2dToNodes.emplaceBack( i, val->GetId( 0 ));
elem2dToNodes.emplaceBack( i, val->GetId( 1 ));
elem2dToNodes.emplaceBack( i, val->GetId( 2 ));
elem2dToNodes.emplaceBack( i, val->GetId( 3 ));
}
void TwoPointFluxApproximation::computeConnectivityIndex( ElementRegionManager & elemManager, | ||
NodeManager & nodeManager, | ||
EmbeddedSurfaceSubRegion & embeddedSurfaceSubRegion ) const | ||
{ | ||
// Launch kernel to compute connectivity index of each fractured element. | ||
elemManager.forElementSubRegionsComplete< CellElementSubRegion >( | ||
[&]( localIndex const, localIndex const, ElementRegionBase &, CellElementSubRegion & subRegion ) | ||
{ | ||
auto kernelVariant = createKernel( subRegion.getElementType(), nodeManager, subRegion, embeddedSurfaceSubRegion ); | ||
|
||
std::visit( [&] ( auto kernel ) | ||
{ | ||
using KERNEL_TYPE = decltype( kernel ); | ||
KERNEL_TYPE::template launchCIComputationKernel< parallelDevicePolicy< >, KERNEL_TYPE >( kernel ); | ||
}, kernelVariant); | ||
} ); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe these changes should be in their own PR. Moving this here should not have any impact on the results.
copy from #3082
Implement EDFM loading and tested it on a simple 2.5D EDFM case. Below is an input example containing 2 fracture elements: