refactor: Preparatory for well to frac connection #3227
Conversation
paveltomin
changed the title
paveltomin
changed the title
paveltomin
requested review from
rrsettgast,
CusiniM,
jhuang2601 and
castelletto1
as code owners
paveltomin
requested review from
francoishamon,
MelReyCG and
corbett5
as code owners
|
@CusiniM, @MelReyCG, @castelletto1, @corbett5, @cssherman, @jhuang2601, @matteofrigo5, @rrsettgast, @untereiner, and/or @wrtobin please review |
|
need review please |
paveltomin
requested review from
Guotong-Ren
and removed request for
cssherman
|
Waiting on code owner review from @CusiniM, @Guotong-Ren, @castelletto1, @frankfeifan, @jhuang2601, @matteofrigo5, @rrsettgast, @ryar9534, @untereiner, @wrtobin, and/or 2 others. |
|
@CusiniM, @Guotong-Ren, @castelletto1, @frankfeifan, @jhuang2601, @matteofrigo5, @rrsettgast, @ryar9534, @untereiner, @wrtobin please review |
|
@CusiniM, @MelReyCG, @castelletto1, @corbett5, @frankfeifan, @jhuang2601, @rrsettgast, @ryar9534, @untereiner, and/or @wrtobin please review, i need to move this forward, it's been a while |
| * @brief Get the target region for a perforation. | ||
| * @return the target regions for a perforation | ||
| */ | ||
| arrayView1d< string const > getPerfTargetRegion() const { return m_perfTargetRegion; }; |
There was a problem hiding this comment.
Just to be sure to understand, it can connect to multiple region if the perforation is at the interface of two or more regions?
There was a problem hiding this comment.
i think it can and the name should "regions", not "region", let me fix it
There was a problem hiding this comment.
oh no, you are right, each perf only connects to one region, sorry my confusion
There was a problem hiding this comment.
Ok, thanks for the explanation! It's clearer now. The returned list of these methods are for perforations data here, it imply something like getPerfsX().
There was a problem hiding this comment.
yes, same pattern as for other functions/perf. data
| registerWrapper( viewKeyStruct::targetRegionString(), &m_targetRegionName ). | ||
| setRTTypeName( rtTypes::CustomTypes::groupNameRef ). | ||
| setInputFlag( InputFlags::OPTIONAL ). | ||
| setDescription( "Target region to connect the perforation" ); |
There was a problem hiding this comment.
Why can it be customized by the user? Cannot it be determined automatically?
There was a problem hiding this comment.
the idea here is to be able to connect well to a fracture
fractures are geometrically zero volume objects so a perforation that lies on a fracture may numerically also get connected to a cell block next to it
to avoid this situation and to allow the user to control the behavior, targetRegion can be optionally specified
when not provided, GEOS will try to connect perforation with all the regions
| real64 const (&GEOS_UNUSED_PARAM( elemCenter ))[3], | ||
| real64 const (&GEOS_UNUSED_PARAM( location ))[3] ) | ||
| { | ||
| // only CellElementSubRegion is currently supported |
There was a problem hiding this comment.
I may be wrong, but this code should not run if not supported.
| // only CellElementSubRegion is currently supported | |
| static_assert( false, "only CellElementSubRegion is currently supported" ); |
There was a problem hiding this comment.
i think it will start crashing if i add that assert
the needed functions are implemented in #3359
hope we can merge both soon
This PR includes preparatory changes for supporting well to frac connections.
CellElementSubRegionwithElementSubRegionBasewhere possibletargetRegionfor perforations, to be able to connect to matrix or fracture (iftargetRegionis not specified that means perforation will try to connect to all regions)connectPerforationsToMeshElementslogic - since target region is already defined, loop through subregions insearchLocalElements, also adjustvisitNeighborElementsandinitializeLocalSearchbut for now preserve old versions of those 3 functions (still used inassignUnownedElementsInReservoir), will unify later