Skip to main content

Case File Configuration

ICV Control extends Completor keywords to be longer. In case of running both Completor and ICV Control, the user will just merge both case file into one single case, or running Completor twice.

Keywords​

This keyword initiates the use of ICV Control. If any of the mandatory keyword is missing, ICV Control will not run.

ICVCONTROL​

This keyword is mandatory and initializes ICV Control script.

  1. Well: Well name (must be identical to the well name specified in the Eclipse file and COMPLETION keyword).
  2. ICV Name: Ensure identical ICV name, maximum 2 characters (number or letter).
  3. ICV Segment number: Segment number corresponds to specific ICV from WSEGVALV keyword. This will be updated accordingly while running WSEGICV keyword from Completor® for the associated wells.
  4. ICV Table: ICV Control requires a flow trim table for specified ICV to be inputted as ICVTABLE in following keywords. It will corresponds on different ICV opening (integer from 1-max number).
  5. STEPS: Number of steps that ICV Control will take to evaluate the criteria. It means if the ICV Control has been operated for more than this steps, it will stop evaluating of the control criteria, and set to be constant until the rest of simulation period. It is recommended to set this as 50, as increasing this number will consume lots of memory in simulation run.
  6. ICVDATE: Start of ICV Operation. Accepted format will be: DD.MMM.YYYY (example: 1.JUL.2023)
  7. FREQ: Number of days after which ICV will be operated again after completing the sequence of WAIT - READY - OPERATE - STOP.
  8. MIN: Minimum ICV position. It is connected to the ICVTABLE keyword in column number 4.
  9. MAX: Maximum ICV position. It is connected to the ICVTABLE keyword in column number 4.
  10. OPENING: Initial ICV position. It is connected to the ICVTABLE keyword in column number 4.

End the record with /

Example:

ICVCONTROL
--  WELL     ICV   SEGM      ICVTABL   STEPS   ICVDATE      FREQ    MIN   MAX    OPENING
   A1      	A1       1        A        50      2.JAN.2020   30      1     10     T10
   A2      	A2       1        A        50      2.JAN.2020   30      1     10     T10
   A3      	A3       1        A        50      2.JAN.2020   30      1     10     T10
   A4      	A4       1        A        50      2.JAN.2020   30      1     10     T10
   OP5     	O1       1        A        50      2.JAN.2020   30      1     10     T10
   OP5     	O2       1        A        50      2.JAN.2020   30      1     10     T10
/

ICVTABLE​

This initiates the ICV Flowtrim table: Line 1: Table name. String/integer character that matches with item number 4 in ICVCONTROL keyword. Ended with /

Next following lines are:

  1. ICV Position Number
  2. Discharge area of ICV (Currently fixed into 1 due to Eclipse limitation)
  3. Valve cross section area.

End record by /

Example:

ICVTABLE
A / -- corresponds to ICVCONTROL keyword number 4
-- POS CD AREA
1	    1	    1.02374E-05
2	    1	    2.84372E-05
3	    1	    4.73954E-05
4	    1	    7.89923E-05
5	    1	    0.0001316
6	    1	    0.0003657
7	    1	    0.0006095
8	    1	    0.001693
9	    1	    0.002821
10	    1	    0.004703
/

CONTROL_CRITERIA​

This keyword is the heart of ICV Control. As the ICVCONTROL keyword initializes, this keyword will fill in the trigger definition, value, and the criteria for The ICV to respond on operation. There are three combination on the required fill of this keyword.

ICV Control uses logic of dictionary, where the ICV defined as a list of ICVs with bracket as [ICV1][ICV2]...[ICVn]. This can be set also as a combination for example [ICV1,ICV2][ICV3,ICV4]...[ICVn,ICVo]. The ICV Control script will translate this variable naming with a subset of _x0, _x1 depending on the length of ICV inside bracket. Therefore if the length is 2, it is expected that the CONTROL_CRITERIA will have two subscript at least starting from _x0.

UDQ Initialization​

This will pre-define the parameterization of the trigger using UDQ keywords.

  1. First line: FUNCTION:

    These combination are accepted as FUNCTION: [UDQ]

    Defining the UDQ functions that are used in the CRITERIUM

  2. Second line: ICV:

    ICV names that are wanted to be triggered by this CONTROL_CRITERIA under this CRITERIUM. Accepted names are the one listed in ICVCONTROL table item number 2.

  3. Third line and so on: Criteria writing as in UDQ definition in the Eclipse language.

End the record with /

Example: Here is an example of the subscript logic of ICV Control, where the ICV is only one in each bracket, therefore expected to have _x0 in the third line and so on.

CONTROL_CRITERIA
 FUNCTION: [UDQ]
 ICV: [O1][O2]
 DEFINE FUWCT_x0 SWCT WELL(x0) SEG(x0) / WWCT WELL(x0)  /  --branch water cut control
/

Different example as follows: This is an example of hard coded variable that will define the operation on ICV O1 and O2. The difference is that this ICV O1 and O2 will respond only to WELL_A segment number 25 of its water-cut. While the previous example, it will respond to what ICV O1 and O2 associated well and segment based on table ICVCONTROL.

CONTROL_CRITERIA
 FUNCTION: [UDQ]
 ICV: [O1][O2]
 DEFINE FUWCT_A SWCT WELL_A 25  /  -- water cut control
/

Parameter target​

The target parameter is usually defining what is target of the defined parameter in previous sub-section, and when it is stop to operate (either chokes or opens).

  1. First line: FUNCTION:

    These combination are accepted as FUNCTION: [UDQ]

    Defining the UDQ functions that are used in the CRITERIUM

  2. Second line and so on: Criteria writing as in UDQ definition in the Eclipse language.

End the record with /

The difference is there is no ICV definition, which sets this as a universal target for all ICVs. It can be added ICVs, but based on experience, it will add degree of complexity without added value.

Example:

CONTROL_CRITERIA
 FUNCTION: [UDQ]
 ASSIGN FUTOL 0.05 /
 ASSIGN FUWCTBRN 1 /
 ASSIGN FUWCTWEL 1.5 /
 DEFINE FUWELMIN FUWCTWEL - FUTOL /
 DEFINE FUWELMAX FUWCTWEL + FUTOL /
 DEFINE FUBRNMIN FUWCTBRN - FUTOL /
 DEFINE FUBRNMAX FUWCTBRN + FUTOL /
/

ICV Operation (mandatory)​

This is the sub-section where the logic of operation goes in. It is constructed as ACTIONX keyword type.

  1. First line: FUNCTION: These combinations are accepted as FUNCTION: [function type]
  • [OPEN, OPEN_WAIT, OPEN_READY] This function triggers ICVs to be opened.
  • [OPEN_STOP, OPEN_WAIT_STOP] This function triggers to stop opening process of ICVs.
  • [CHOKE, CHOKE_WAIT, CHOKE_READY] This function triggers ICVs to be choked.
  • [CHOKE_STOP, CHOKE_WAIT_STOP] This function triggers to stop choking process of ICVs.

The first four are functions to define ACTIONX criteria. These functions need to be related to each other and designed in a manner that they will not conflict with each other (open criteria should not be similar to stop choke, and choke criteria should not trigger stop open). STOP functions have the purpose of stopping the continuous trial of opening/closing of ICVs. UDQ functions are custom criteria that you can put as the criteria in these OPEN, CHOKE, and STOPS. 2. Second line: CRITERIUM:

Accepted are integer numbers for sets of criterium CRITERIUM: integer 3. Third line: ICV:

ICV names that are wanted to be triggered by this CONTROL_CRITERIA under this CRITERIUM. Accepted names are the ones listed in ICVCONTROL item number 2. 4. Fourth line and so on:

Criteria writing as in UDQ and ACTIONX language of Eclipse

End the record with /

Example: This is an example where each ICVs O1 and O2 are behaving dependent on the value of FUWCTBRN. The logic implemented are: If the value of FUWCT in each ICV _x0 is less than FUWCTBRN and the ICV position in FUPOS_x0 is less than 10 (maximum position), it will trigger to open. On the contrary, if the value is more than FUWCTBRN and the ICV position FUPOS_x0 is more than 1 (minimum position), it will trigger to close. A STOP function is always there associated to each OPEN and CLOSE function to prevent over reacting on the ACTIONX keywords, it puts as a tolerance band in predefined UDQ FUBRNMIN and FUBRNMAX defined in previous constant section.

-------------------WATERCUT BRANCH CONTROL------------------------
CONTROL_CRITERIA
 FUNCTION: [OPEN, OPEN_WAIT, OPEN_READY]
 CRITERIUM: 1
 ICV: [O1][O2]
 FUWCT_x0 < FUWCTBRN AND /
 FUPOS_x0 < 10 /
/
CONTROL_CRITERIA
 FUNCTION: [OPEN_STOP, OPEN_WAIT_STOP]
 CRITERIUM: 1
 ICV: [O1][O2]
 FUWCT_x0 > FUBRNMIN
/
CONTROL_CRITERIA
 FUNCTION: [CHOKE, CHOKE_WAIT, CHOKE_READY]
 CRITERIUM: 1
 ICV: [O1][O2]
 FUWCT_x0 > FUWCTBRN AND /
 FUPOS_x0 > 1 /
/
CONTROL_CRITERIA
 FUNCTION: [CHOKE_STOP, CHOKE_WAIT_STOP]
 CRITERIUM: 1
 ICV: [O1][O2]
 FUWCT_x0 < FUBRNMAX
/