Model with 3 wells does not converge at second time step

[RayEGU]

Hi all,

We're working on a CO2 injection model in a tetrahedral grid with 3 injectors : Well 1 has 3 perforations, 2 perforations for Well 2 and 5 perforations for Well 3. This case was run with:

• PANGEA-2 machine

• gcc 8.3.0 compiler

We noticed at the second time-step (t=100s) that the solutions nonconverged and the well control of Well 3 switcthed from rate constraint to BHP constraint, then from BHP constraint to total volumetric rate constraint. Even though we changed the BHP from 1000 bars to 8000 bars, we got the same results of non convergence. Here is the simulation folder with the log file " job_GEOS_256168.out" TestWell.zip

[dkachuma]

I think ultimately, the well connections are in poor rocks leading to extremely low values for the calculated well transmissibility. These low values need extremely high pressures to inject and, in the end, result in convergence failures.

@RayEGU Can you please check that the well perforations are in the intended regions. Especially for well_3 which has the smallest transmissibility values.

Please also take note of messages like this in the log

The GEOSX wells currently have the following limitation in parallel: 
We cannot allow an element of the well mesh to have two or more perforations associated with it. 
So, in the present simulation, perforation #2 of well well_3 (simulationA.xml, l.115) is moved from { 800, 742.759, -150 } to { 800, 742.759, -30 } to make sure that no element of the well mesh has two perforations associated with it. 
To circumvent this issue, 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. 

This means that the perforation might not be where you expect it to be. I would recommend manually discretising the well trajectory instead of relying on numElementsPerSegment - this will give the flexibility to ensure that you have a single perforation per segment.

We are working on improving the input for wells which will hopefully ease some of these issues. Please see #2347

Other things to take note of

• The BHP reference elevation for the wells is 7500m which is way above the mesh. The top of the mesh is 396m. I would recommend setting this near the elevation of the perforations.
• You can set logLevel="1" on WellControls and logLevel="2" on InternalWell to get more info in the log about the connections and the BHP.

[RayEGU]

@dkachuma , thanks for the tips. I changed the permeability to 1000 mD for all the model and increased the porosities too. Then, the BHP reference elevation was set to 396.646 m. So, I got some issues :

1. for MPI rank number n = 1 and in surface conditions (useSurfaceConditions = "1", surfacePressure="101325", surfaceTemperature="288.71"), when I increased the flowrate from 0.03 sm3/s to { 0.3; 3; 30; 10,000; 50,000 or 100,000} sm3/s, Geos works very well. But, when I switch to reservoir conditions (useSurfaceConditions = "0"), Geos works just for the flowrates { 0.03; 0.3; 3} rm3/s, and I got the error "Floating point exception " for the flowrates { 15; 30; 50} rm3/s

2. for MPI rank number = 16, and when the wells are discretised in function of perforations number, Geos works in the case of surface conditions but not in reservoir conditions case for a flowrate =30 m3/s.

PS: I adapted the targetBHP depending on tests.

[dkachuma]

@RayEGU Can I please confirm that the nature of the problem has changed? You're now getting a floating point exception when you use reservoir conditions at higher flow rates? But the convergence problems are not being encountered anymore?

[RayEGU]

@dkachuma I confirm that the natutre of the problem has changed. Actually, I'm testing the model using high flowtares both in reservoir conditions and surface conditions. I don't think it's a non-convergence problem cause I got the error just after the first Newton iteration at t = 0 s.

[dkachuma]

@RayEGU Can you please attach the relevant cases for the setups described. I had hoped to reproduce from the description but I am having difficulty.

[paveltomin]

@RayEGU ?