GEOSX crashed, probably related to perforations

[wdmhouston]

Hi @francoishamon,

Can you take a look at this model with some low permeability layers in middle?  This extracted small grid contains only 23 layers with perforations in high perm layers only.  Geosx always fails to converge since beginning.

modelfail_base.zip

I tried and didn't find any way to make it work. I suspect it's related to something, for example, perforations.

Here are grid tops and perforation tags for each layer,
Layer, grid top z, perforation tag(1 yes, 0 no)
1 163.068 1
2 160.02 1
3 156.972 1
4 153.924 0
5 142.9512 1
6 139.9032 1
7 136.8552 0
8 116.1288 1
9 113.0808 1
10 110.0328 1
11 106.9848 1
12 103.9368 1
13 100.8888 1
14 97.8408 0
15 76.8096 1
16 73.7616 1
17 70.7136 1
18 67.6656 0
19 15.24 1
20 12.192 1
21 9.144 1
22 6.096 1
23 3.048 1
bottom 0

The following are well element center, node, and perforation location reported from GEOSX(develop branch).
index, well center z, index, well node z, Distance from head, index, perforation z, attached to well element
0 158.777 0 163.068 0 0 162.968 #0
1 150.194 1 154.485 8.58253 1 162.968 #0
2 141.612 2 145.903 17.1651 2 162.968 #0
3 133.029 3 137.32 25.7476 3 142.851 #2
4 124.447 4 128.738 34.3301 4 142.851 #2
5 115.864 5 120.155 42.9126 5 116.029 #5
6 107.282 6 111.573 51.4952 6 116.029 #5
7 98.6991 7 102.99 60.0777 7 109.933 #6
8 90.1165 8 94.4078 68.6602 8 109.933 #6
9 81.534 9 85.8253 77.2427 9 109.933 #6
10 72.9515 10 77.2427 85.8253 10 100.789 #7
11 64.3689 11 68.6602 94.4078 11 76.71 #10
12 55.7864 12 60.0777 102.99 12 76.71 #10
13 47.2039 13 51.4952 111.573 13 76.71 #10
14 38.6214 14 42.9126 120.155 14 15.14 #17
15 30.0388 15 34.3301 128.738 15 15.14 #17
16 21.4563 16 25.7476 137.32 16 15.14 #17
17 12.8738 17 17.1651 145.903 17 5.996 #18
18 4.29126 18 8.58253 154.485 18 5.996 #18
19 0 163.068

All perforations are located in each high perm layers perfectly in xml file, and the simulation is supposed to be able to converge easily.
Any idea why GEOSX always fails to converge?

[francoishamon]

Hello @wdmhouston

Sorry about this problem. Yes, there are two issues, one is easy to fix, for the other issue, I need to ask a few questions to my colleagues to see if there is a proper way to solve the issue:

Issue 1:
GEOSX outputs this warning:

Please increase the value of "numElementsPerSegment" that controls the number of (uniformly distributed) well mesh elements per segment of the well polyline. 
Our recommendation is to choose "numElementsPerSegment" such that each well mesh element has at most one perforation. 

In this case, I would recommend you to increase the numElementsPerSegment until the warning disappears. As mentioned in the warning, for now we recommend setting up the problem with at most one perforation per well element. For your input file: choose numElementsPerSegment=50, the warning will disappear and the simulation will work fine.

(On the long term, I am planning to get rid of this numElementsPerSegment and compute it internally, but this new version is not ready).

Issue 2:
For the rate that you have chosen, there is a lot of crossflow taking place in the well, which ends up making the simulation extremely difficult. Here is what is happening in the well:

• Perforations 0 to 14 at the top of the reservoir are injecting CO2 in the reservoir (flow from the well to the reservoir).
• Perforations 15 to 18 at the bottom of the reservoir are actually not injecting CO2 and experience flow from the reservoir to the well (because the injection rate is too small). So in your current setup, the brine is actually entering the well at the bottom of the reservoir, and moving up the well to the upper layers.

But because I did not implement enough logging in the well code, you do not have any way to figure out that this is happening, so I will add so warnings about that. I also need to ask around to know if what is the good way to deal with such a large crossflow.

In the meantime, to get rid of crossflow in the well, just increase the totalVolRate (say, double it to 0.024 in the table) and the simulation is going to work fine until the end (or alternatively, keep the totalVolRate as is and shorten the well).

[wdmhouston]

@francoishamon ,

Thanks! Let me try.