feat: Perforation Status #3587

tjb-ltk · 2025-03-07T19:02:38Z

Assign perforations an open/closed state from user specified time vs status table
Dt selection includes perforation table time
Calculations for inactive perforations will be skipped, but linear solver Awr and Arw arrays are still allocated.
- this could be fixed in different PR
Well element state introduced to allow closing/opening of segments
- an element is open if it contains an open perforation, or an upstream element is open
- Aww = I for closed element entries
4 integrated tests introduced to test vertical well where perforations are
- plugged from bottom to top and top to bottom
- opened from bottom to top and top to bottom

…ate Awr Arw for closed perfs

…omms so all cores have segment status (not tested)

… perfs are closed

… constraint , accum, vol bal, and flux calcs

… res numbering, 2) seg skip for p-bal eqn in wrong place

…ove mtx output

dkachuma

Looks good to me.

I have a more paradigm question: We are asking the user to provide the perforation status as a 2D array and then we're using this to internally generate a table. Wouldn't it be simpler to just ask the user to provide the table? This would facilitate:

Very long and complex open/shut sequences can be relegated to a text file instead of clattering the xml.
If the user wants to control multiple perforations in the same way they can define this in one table.

src/coreComponents/mesh/Perforation.cpp

src/coreComponents/unitTests/wellsTests/testOpenClosePerf.cpp

tjb-ltk · 2025-05-05T18:05:17Z

Looks good to me.

I have a more paradigm question: We are asking the user to provide the perforation status as a 2D array and then we're using this to internally generate a table. Wouldn't it be simpler to just ask the user to provide the table? This would facilitate:

Very long and complex open/shut sequences can be relegated to a text file instead of clattering the xml.

If the user wants to control multiple perforations in the same way they can define this in one table.

I'm not aware of the workflows used by the environment developers for GEOS... I assumed

when the perforation info for xml is being generated the perf status is also available.
inlining the status info in the Perf object would avoid one level of indirection (the well model generates the table function, not user).
the timing of open/close is/could be different for perfs. so one coordinate for all perfs isn't ideal and each perf needs its own table

Are you referring to something like below, I can see it has advantages to allow using a separate file , which is fairly straightforward to make the changes...

<InternalWell
name = "well1"
<Perforation
name="perf1"
statusTable="well1_perf1_table"
..

CusiniM

A few small questions and I think I think that the the way these global status arrays are used deserves some broader discussion to at least generalize this patter because it's different from anything else in geos.
@rrsettgast should have a look at this before it goes in.

CusiniM · 2025-06-18T20:01:09Z

src/coreComponents/mesh/Perforation.cpp

+  registerWrapper( viewKeyStruct::perfStatusTableString(), &m_perfStatusTable ).
+    setInputFlag( InputFlags::OPTIONAL ).
+    setSizedFromParent( 0 ).
+    setDescription( "Table defining perforation status as a function of time. If enterned in Functions section, the name must be the same as the perforation name" );


which name must be the same? the name of the function must match the name of the perforation? We should have an attribute to define the function associated to each perf so that multiple perfs can use the same function.

submitted changes to allow user defined perf status table names

CusiniM · 2025-06-18T20:02:12Z

src/coreComponents/mesh/Perforation.cpp

+  // Setup perforation status function
+  FunctionManager & functionManager = FunctionManager::getInstance();
+
+  if( !functionManager.hasGroup< TableFunction >( getName() ) )


here you could pass the name of the function instead of using the perf name and requiring the function name to be the same.

submitted changes to allow user defined perf status table names

CusiniM · 2025-06-18T20:03:13Z

src/coreComponents/mesh/PerforationData.hpp

+  string_array m_perfName;
+
+  /// Local perforation's status
+  array1d< localIndex > m_localPerfStatus;


what's the local perf status?

local means the mesh partition contains that perforation, status means open or closed. Better comment added

CusiniM · 2025-06-18T20:04:12Z

src/coreComponents/mesh/WellElementRegion.cpp

    if( perforationData->globalToLocalMap().count( iperfGlobal ) > 0 )
    {
-      elemStatusGlobal[iwelemGlobal] |= WellElementSubRegion::WellElemStatus::LOCAL;
+      elemStatusGlobal[iwelemGlobal] |= WellElementSubRegion::WellElemParallelStatus::LOCAL;
    }
    else
    {
-      elemStatusGlobal[iwelemGlobal] |= WellElementSubRegion::WellElemStatus::REMOTE;
+      elemStatusGlobal[iwelemGlobal] |= WellElementSubRegion::WellElemParallelStatus::REMOTE;


can you add some comments? I am not sure I follow what's happening? what's the meaning of remote and local in this context?

These are defined in header where the struct is defined. Several well elements data structures are mirrored on all cores. Remote/local is used to identify if the element is spatially located on a different ranks mesh partition.

CusiniM · 2025-06-18T20:14:21Z

src/coreComponents/physicsSolvers/multiphysics/SinglePhaseReservoirAndWells.cpp

+              localMatrix.addToRowBinarySearchUnsorted< parallelDeviceAtomic >( eqnRowIndices[i],
+                                                                                &dofColIndices[0],
+                                                                                &localPerfJacobian[0][0] + 2 * i,
+                                                                                2 );
+              RAJA::atomicAdd( parallelDeviceAtomic{}, &localRhs[eqnRowIndices[i]], localPerf[i] );


Looking at this I would say that if the perf is closed there will be a zero on the diagonal but clearly I am missing where the diagonal is being set.

In the accumulation kernel

src/coreComponents/physicsSolvers/fluidFlow/wells/CompositionalMultiphaseWell.cpp

CusiniM · 2025-06-18T20:24:42Z

src/coreComponents/physicsSolvers/fluidFlow/wells/CompositionalMultiphaseWell.cpp

+        arrayView1d< integer const > const elemStatus =subRegion.getLocalWellElementStatus();
+        array1d< real64 > & mixConnRate =  subRegion.getField< fields::well::mixtureConnectionRate >();
+        localIndex rank_offset = dofManager.rankOffset();
+        forAll< serialPolicy >( subRegion.size(), [=] GEOS_HOST_DEVICE ( localIndex const ei )


why serialPolicy? this forces it to happen on host.

good eye... changed to parallel

CusiniM · 2025-06-18T20:26:25Z

src/coreComponents/physicsSolvers/fluidFlow/wells/CompositionalMultiphaseWell.cpp

+                localMatrix.template addToRow< serialAtomic >( rindex,
+                                                               &cindex,
+                                                               &unity,
+                                                               1 );
+                localRhs[rindex] = 0.0;


@castelletto1 , @victorapm will this cause issues to the LS? I am guessing that ideally we would like to have a diagonal entry reasonably scaled with the rest of the diagonal entries in the system.

This is already the current behavior and not introduced by this PR. If this needs to be changed it can be addressed in new PR @CusiniM, @castelletto1 , @victorapm

src/coreComponents/mesh/Perforation.cpp

src/coreComponents/unitTests/wellsTests/testOpenClosePerf.cpp

MelReyCG · 2025-07-21T15:44:00Z

src/coreComponents/mesh/Perforation.cpp

+    setRTTypeName( rtTypes::CustomTypes::groupNameRef ).
+    setInputFlag( InputFlags::OPTIONAL ).
+    setDescription(
+    "Name of table function defining perforation status as a function of time. If none specified, a table function with be created internally and assigned the same name as the perforation." );


Maybe add precisions / example:

Suggested change

"Name of table function defining perforation status as a function of time. If none specified, a table function with be created internally and assigned the same name as the perforation." );

"Name of table function defining perforation status as a function of time:\n"

"- The first row sets the perforation time coordinates,\n"

"- The following row is a multiplier of the perforation rate (typically, 0.0 to close, 1.0 to open) for each time coordinate.\n"

"If none specified, a table function with be created internally and assigned the same name as the perforation.\n"

"A table that opens the perforation at t=100, and closes it at t=200 could be `{{ 0, 100, 200 },{ 0.0, 1.0, 0.0 }}`" );

Thanks ... good suggestion I've added the description with a slight modification. The intent of perf status is to be an on/off indicator, with potentially other statuses as needed for well actions. The fractional value I think you are referring to would be a PI multiplier field.

src/coreComponents/mesh/Perforation.cpp

Co-authored-by: MelReyCG <[email protected]>

tjb-ltk added 2 commits March 3, 2025 14:25

1) add perf status array, 2) skip calcs if perf closed, 3) dont alloc…

7d47dbb

…ate Awr Arw for closed perfs

1) Allocate Awr Arw space for all perforations(open&closed), 2) add c…

2d278e6

…omms so all cores have segment status (not tested)

tjb-ltk added the type: feature New feature or request label Mar 7, 2025

tjb-ltk self-assigned this Mar 7, 2025

tjb-ltk requested review from rrsettgast, CusiniM, paveltomin, castelletto1, frankfeifan, jhuang2601, Guotong-Ren, dkachuma, wrtobin and untereiner as code owners March 7, 2025 19:02

1) add parallel comms to sync well element state, 2) shut well if all…

fd58aa1

… perfs are closed

tjb-ltk changed the title ~~Feat : Perforation Status~~ feat : Perforation Status Mar 7, 2025

tjb-ltk marked this pull request as draft March 7, 2025 19:10

tjb-ltk and others added 13 commits March 10, 2025 15:01

create TableFunction from Perforation status arrays

1589fe1

compiler error fix

73577e5

set perf status from table function at start of timestep

110bd89

forgot a few

c18ad3a

rel compile fixes

6870b0b

use status instead of state to id perf/seg open/close condition

0b3c212

For closed well elements 1) set Aww=I for closed seg cleanup, 2) skip…

1f7b47e

… constraint , accum, vol bal, and flux calcs

1) fix seg open/close logic, seg indices in reverse order compared to…

6487c9c

… res numbering, 2) seg skip for p-bal eqn in wrong place

remove debug

d854a9b

fix to zero rate for closed segs

8a54e71

merge error

0c79126

parallel fixes

a5f1dae

Merge branch 'develop' into feature/byer3/well_time_dep_perf_status

7006ba8

fix input error check , skip calc if well is shut, add unit test, rem…

fc9d087

…ove mtx output

tjb-ltk requested review from corbett5 and MelReyCG as code owners May 2, 2025 16:48

one more file

fbb0acc

dkachuma approved these changes May 2, 2025

View reviewed changes

src/coreComponents/mesh/Perforation.cpp Show resolved Hide resolved

src/coreComponents/unitTests/wellsTests/testOpenClosePerf.cpp Outdated Show resolved Hide resolved

tjb-ltk added 2 commits May 2, 2025 15:30

fix rel mode compile errors

ec0a6b4

remove unused var

a80977e

tjb-ltk added 3 commits May 22, 2025 08:23

merge devel

98e66c8

fix merge

a2e0387

more merge fixes

6da8e22

CusiniM reviewed Jun 18, 2025

View reviewed changes

tjb-ltk and others added 10 commits June 24, 2025 08:50

1) clarify comments, 2) change compute policy to parallel

b305b48

better comment

fc9c472

allow perf status table to defined as function table

512df38

Merge branch 'develop' into feature/byer3/well_time_dep_perf_status

16f5dc6

try adding stack trace to ChaiBuffer constructor to get location of call

0669f1a

revert

a95f41c

revert stackTrace call. change mixConnRate to a view

08063cb

Merge branch 'develop' into feature/byer3/well_time_dep_perf_status

5818641

Merge branch 'develop' into feature/byer3/well_time_dep_perf_status

b16dc49

fix merge errors

2ffb2db

MelReyCG reviewed Jul 21, 2025

View reviewed changes

tjb-ltk and others added 7 commits July 22, 2025 07:24

Update src/coreComponents/mesh/Perforation.cpp

d2e3e80

Co-authored-by: MelReyCG <[email protected]>

Update src/coreComponents/mesh/Perforation.cpp

69c38a2

Co-authored-by: MelReyCG <[email protected]>

improve naming

35fc658

review changes

d3dc717

Merge branch 'develop' into feature/byer3/well_time_dep_perf_status

8494b2f

fix merge error

051a4ca

fix throw check

488968f

-    "Name of table function defining perforation status as a function of time. If none specified, a table function with be created internally and assigned the same name as the perforation." );
+    "Name of table function defining perforation status as a function of time:\n"
+    "- The first row sets the perforation time coordinates,\n"
+    "- The following row is a multiplier of the perforation rate (typically, 0.0 to close, 1.0 to open) for each time coordinate.\n"
+    "If none specified, a table function with be created internally and assigned the same name as the perforation.\n"
+    "A table that opens the perforation at t=100, and closes it at t=200 could be `{{ 0, 100, 200 },{ 0.0, 1.0, 0.0 }}`" );

feat: Perforation Status #3587

Are you sure you want to change the base?

feat: Perforation Status #3587

Uh oh!

Conversation

tjb-ltk commented Mar 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dkachuma left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tjb-ltk commented May 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CusiniM left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tjb-ltk commented Mar 7, 2025 •

edited

Loading

tjb-ltk commented May 5, 2025 •

edited

Loading

CusiniM left a comment •

edited

Loading