Wells Not Flowing in 2019-04

[OPMUSER]

It is common practise to declare all wells and their completions, VLPs etc at the beginning of the SCHEDULE section, and to SHUT all the wells and completions at this time. During the run wells are opened using the WELOPEN keyword for example using:

--
--       DEFINE WELL AND WELL CONNECTIONS FLOWING STATUS                                                
--                                                                              
--  WELL WELL   --LOCATION--  COMPLETION                                     
--  NAME STAT     I   J    K  FIRST LAST                    
WELOPEN                                                     
OP01     OPEN                                                                  /
OP01     OPEN     0   0    0     3     3                                       /
GI01     OPEN                                                                  /
GI01     OPEN     0   0    0     1     1                                       /
/  

This does not work in OPM Flow but does in the commercial simulator. Even worst if the wells are initially SHUT and all the completions are initially SHUT, one cannot put the wells back on production using the WCONPROD and COMPDAT keywords etc.- the wells are permanently shut-in.

I have attached various test cases based on the SPE01 case for reference:

1. R01: Base case with the wells on production immediately, as expected this case works.
2. R02: All wells and completions are SHUT at time zero, and then opened up after one year using the WELOPEN keyword - wells do not produce.
3. R03: Same as R02 but with WCONPROD AND WCONINJE used to open the wells and WELOPEN to open the completions - wells do not produce.
4. R04: Same as R03 with WCONPROD AND WCONINJE used to open the wells but with COMPDAT to open the completions - wells do not produce.

SPE01.zip

[GitPaean]

Re-opening connections with WELOPEN is supported. Norne has some operations like that.

But not sure about Re-opening with completions numbers.

Can you tell me what you are expecting through the following operations? I mean why you open the well twice?

WELOPEN
OP01     OPEN                                                                  /
OP01     OPEN     0   0    0     3     3                                       /

The first line of OP01 OPEN / did not manage to re-open the well?

[GitPaean]

I will take a look at the cases you uploaded when I find time later today.

[OPMUSER]

The first WELOPEN opens the well the second opens the completions, because both the well and the completions are SHUT.

However, even if you use the actual connections as per the test cases, you cannot bring the wells back on production. So it is something more fundamental than the COMPLUMP and WELOPEN keywords.

[GitPaean]

However, even if use the actual connections as per the test cases, you cannot bring the wells back on production. So it is something more fundamental than the COMPLUMP and WELOPEN keywords.

I will get back to it later today.

[alfbr]

We have had several rounds testing COMPLUMP over here. More specifically, we have tested (and confirmed working at the time) COMPLUMP+WECON, COMPLUMP+WELOPEN and COMPLUMP+WPIMULT. We did have uncertainties regarding WTEST+COMPLUMP, but that has resulted in the ongoing effort of fixing the WTEST support. We still miss regression tests covering all combinations, contributions there is highly welcome.

[GitPaean]

@OPMUSER , for the CASE R02, what is the behavoir for the commericial simulator?

For this case, for the well OP01, you claim one connection with COMPDAT, which is shut at the beginning. There is no COMPLUMP keyword, so basically the only connection will have a completion number 1.

In the WELOPEN, you open the well OP01 first. Then you tried to open the completion 3, which does not exist. As a result all the connections will remain SHUT. Then for this well has no OPEN connections, as a result, it will not operate.

Please let me know if I misread anything here? And also please let me know the behavoir from the commercial simulator, and what should the expected behavoir.

I have not looked at the case R03 and R04 at the moment. Let us discuss and understand the issue better first.

[OPMUSER]

@GitPaean Yes I know this is confusing, even for me after all these year :-).

The WELOPEN keyword applies to both connections and completions. If COMPLUMP has been activated for the well then:

--
--       DEFINE WELL AND WELL CONNECTIONS FLOWING STATUS                        
--                                                                              
--  WELL WELL   --LOCATION--  COMPLETION                                     
--  NAME STAT     I   J    K  FIRST LAST                    
WELOPEN                                                     
OP01     OPEN                                                                  /
OP01     OPEN     0   0    0     3     3                                       /
/

Will open connections in completion number 3. As COMPLUMP has not be used, then OPM Flow should open connections in layer number three. This is what the commercial simulator does.

Is that clear?

[GitPaean]

Will open connections in completion number 3. As COMPLUMP has not be used, then OPM Flow should open connections in layer number three.

For WELOPEN keyword, the item 6 and 7 are for completion numbers. You mean, because there is no COMPLUMP keyword, the item 6 and (or) 7 will become location index?

If it is the case, then it is really confusing and OPM for sure does not support it yet.

Basically, in my understanding, connections have to satisfy the I J K location index AND the completion number range (item 6 and 7) BOTH to make the WELOPEN apply to the connection.

Another question here, if you do not use the second line OP01 OPEN 0 0 0 3 3 /, will the commercial simulator manage to open the well?

[GitPaean]

For WELOPEN keyword, the item 6 and 7 are for completion numbers. You mean, because there is no COMPLUMP keyword, the item 6 and (or) 7 will become location index?

Or the other way, because there is no COMPLUMP keyword, we should not consider the item 6 and 7. Then it should open all the connections because all zeros for I J K location indices?

The problem with this is that even we do not have a COMPLUMP keyword, a default completion number will be generated based on the order that we claim the connections.

[OPMUSER]

Its late here, so I'll investigate further tomorrow and get back to you.

[OPMUSER]

OPM Flow definitely has a problem when wells and completions are declared as shut, and then trying to re-open them at a later date - this never works in OPM Flow, but works in the commercial simulator (depending on how the run is setup).

I have attached a pdf file with the results of seven cases for both the commercial simulator and OPM Flow; the plots are after the table. I have also attached the input decks in the attached zip file.

It appears if COMPLUMP has not been entered, then a default value of 1 is used for all connections declared on COMPDAT, so using

--                                       
--  WELL WELL   --LOCATION--  COMPLETION 
--  NAME STAT     I   J    K  FIRST LAST 
WELOPEN                                  
OP01     OPEN                            /
OP01     OPEN     0   0    0     1     1 /
GI01     OPEN                            /
GI01     OPEN     0   0    0     1     1 /
/  

Will open these connections for both wells, layer 3 for OP01 and layer 1 for GP01. I don't have a firm opinion if OPM Flow should behave the same or not, as long as we document the behaviour in the manual. However, we still have a issue with OPM Flow not opening wells.

SPE01-BASE04 WELOPEN Cases Documentation Rev-A.pdf

SPE01-BASE04.zip

[joakim-hove]

It appears if COMPLUMP has not been entered, then a default value of 1 is used for all connections declared on COMPDAT, so using

When connections are created with the COMPDATkeyword they are assigned a running COMPLUMP number, one to the first connection, two to the second and so on.

[GitPaean]

It appears if COMPLUMP has not been entered, then a default value of 1 is used for all connections declared on COMPDAT, so using

Let us only discuss the case R02. The well only has one connection, when there is no COMPLUMP keyword, this connection gets a completion number 1. This is the rule defined in the manual.

Since you use the following WELOPEN

WELOPEN                                                     
OP01     OPEN                                                                  /
OP01     OPEN     0   0    0     3     3                                       /
/

There is no completion number between 3 and 3. As a result, OPM will not open any completion, since there is no completion in the specified the range 3 to 3 .

The only connection has completion number 1, as a result, you can use the following WELOPEN to open it (which you mentioned already.)

--                                       
--  WELL WELL   --LOCATION--  COMPLETION 
--  NAME STAT     I   J    K  FIRST LAST 
WELOPEN                                  
OP01     OPEN                            /
OP01     OPEN     0   0    0     1     1 /

If the commercial simulator did open the completion with OP01 OPEN 0 0 0 1 1 /, then we have to find the rationale behind it. As far as I can see, the OPM is doing what is supposed to be done.

For the case R02, can you try to add the following COMPLUMP to see what happens.

COMPLUMP OP01 0 0 3 3 2 / /

I attached the modified R02 case for you to test. Please share the well rates and bhps for the two wells from the commercial simulator.

R02.zip

[GitPaean]

The other setup in the R02 case can play a role is related to WELLDIMS . In this setup, the second item is 1, which makes the only legal completion number is 1. One of the possibility that the commercial simulator does here, is it ignore the completion number 3 specified in the WELOPEN. The as a result, then open all the connections since the I J K are defaulted.

 55 WELLDIMS
 56 -- Item 1: maximum number of wells in the model
 57 --     - there are two wells in the problem; injector and producer
 58 -- Item 2: maximum number of grid blocks connected to any one well
 59 --     - must be one as the wells are located at specific grid blocks
 60 -- Item 3: maximum number of groups in the model
 61 --     - we are dealing with only one 'group'
 62 -- Item 4: maximum number of wells in any one group
 63 --     - there must be two wells in a group as there are two wells in total
 64    2 1 1 2 /
 65 

[GitPaean]

For the case2,

I really want to see the plots of the rates and bhps for the two wells to understand the curves. I am really confused.

[OPMUSER]

@joakim-hove

When connections are created with the COMPDAT keyword they are assigned a running COMPLUMP number, one to the first connection, two to the second and so on.

Yes, you are correct, this is indeed the case - my mistake

[OPMUSER]

Case R02 (Part I)

@GitPaean the reason the GI01 wells opens in the R02 case in commercial simulator is that the connection (1) as been assigned completion 1, as mentioned by @joakim-hove. Also that is why OP01 does not open up in the commercial simulator as the connection in layer 3 has completion number one. So everything works as intended in the commercial simulator.

So why does OPM Flow not open GI01, like the commercial simulator?

Well comparison plots for my R02 cases below.

[GitPaean]

So why does OPM Flow not open GI01, like the commercial simulator?

OPM flow opens GI01

flow-master$ summary.x SPE01-BASE04-OPM1904-R02. WGIR:GI01 WBHP:GI01
-- Days   dd/mm/yyyy          WGIR:GI01        WBHP:GI01 
---------------------------------------------------------
   1.00   02/01/2015                  0                0 
   4.00   05/01/2015                  0                0 
  13.00   14/01/2015                  0                0 
  31.00   01/02/2015                  0                0 
  59.00   01/03/2015                  0                0 
....
 212.00   01/08/2015                  0                0 
 243.00   01/09/2015                  0                0 
 273.00   01/10/2015                  0                0 
 304.00   01/11/2015                  0                0 
 334.00   01/12/2015                  0                0 
 365.00   01/01/2016                  0                0 
 396.00   01/02/2016             100000          7682.56 
 396.19   01/02/2016             100000          7677.94 
 396.78   01/02/2016             100000          7662.76 
 398.53   03/02/2016             100000          7602.12 
 403.78   08/02/2016             100000           7536.6 
 417.08   22/02/2016             100000          7561.07 
 424.00   29/02/2016             100000          7578.86 
 439.50   15/03/2016             100000          7744.09 
 455.00   31/03/2016             100000           7966.6 
 485.00   30/04/2016             100000          8397.39 
 516.00   31/05/2016             100000          8970.08 
 546.00   30/06/2016              69579             9014 
 577.00   31/07/2016            48223.8             9014 
 608.00   31/08/2016            38287.6             9014 
 638.00   30/09/2016            26117.8             9014 
 669.00   31/10/2016            17763.7             9014 
 699.00   30/11/2016              12003             9014 
 730.00   31/12/2016            7944.94             9014 
 761.00   31/01/2017            5217.22             9014 
 789.00   28/02/2017            3528.79             9014 
 820.00   31/03/2017            2304.67             9014 
 850.00   30/04/2017            1505.86             9014 
 881.00   31/05/2017            983.912             9014 
 911.00   30/06/2017            641.336             9014 
 942.00   31/07/2017            407.124             9014 
 973.00   31/08/2017            255.707             9014 
1003.00   30/09/2017            161.625             9014 
1034.00   31/10/2017            99.6825             9014 
1064.00   30/11/2017            61.1259             9014 
1095.00   31/12/2017             35.698             9014 
1126.00   31/01/2018            19.4738             9014 
1154.00   28/02/2018            9.76027             9014 
1185.00   31/03/2018            2.91489             9014 
1215.00   30/04/2018           0.667947             9014 
1246.00   31/05/2018          0.0267179             9014 
1276.00   30/06/2018         0.00106872             9014 
1307.00   31/07/2018        4.27486e-05             9014 
1338.00   31/08/2018        1.70994e-06             9014 
1368.00   30/09/2018        6.83978e-08             9014 
1399.00   31/10/2018        2.73591e-09             9014 
1429.00   30/11/2018        1.09436e-10             9014 
1460.00   31/12/2018        4.37746e-12             9014 
1491.00   31/01/2019        1.75098e-13             9014 
1519.00   28/02/2019        7.00393e-15             9014 
1550.00   31/03/2019        2.80157e-16             9014 
1580.00   30/04/2019        1.12063e-17             9014 
1611.00   31/05/2019        4.48252e-19             9014 
1641.00   30/06/2019        1.79301e-20             9014 
......
3650.00   29/12/2024                  0             9014 

SPE01-BASE04-OPM1904-R02.DATA_0701.pdf

[GitPaean]

I guess this issue was closed by accident.

[GitPaean]

Well comparison plots for my R02 cases below.

The plots just shows up. The WGIR curve is same with the one produced by OPM-flow.

[OPMUSER]

Yes, two many screens and too many VMs - couldn't see how to re-open it.

My version definitely does not open, I'm running 2019-04 Ubuntu.

[GitPaean]

My version definitely does not open, I'm running 2019-04 Ubuntu.

okay. It is possible that something wrong with the 2019-04 release version. Let me check.

[GitPaean]

I am using installed libecl, it might not be very easy for me to test the release version. I am a little occupied. I will get back to it when I find some time later.

[OPMUSER]

Any news?