Treatment of duplicate wells

[olwijn]

Flownet builds a simulation schedule from reported data (either a database or a simulated Eclipse case). For WAG wells, if the switch from gas to water injection (or vice versa) takes place within a single reporting period, of e.g. one month, both gas and water injection rates may be reported for the same well. In Eclipse schedule files this is sometimes handled by defining 2 separate wells to represent the 2 injection phases of the same physical well. FlowNet will try to create connections between these wells that will have a length of 0, which does not make any sense and will cause problems in the workflow. A similar situation can occur when wells are converted from e.g. producers to injectors and are given a new name in the schedule.

A solution would first of all require informing FlowNet that wells that are at the same location should result in only 1 well node. Relying on similarity in well names will not be sufficiently robust, so a check on WELSPECS or even COMPDAT entries would be required.

When an injection phase or well type change occured within a reporting period (or between 2 DATES entries in an Eclipse schedule used as input data), Flownet will have to insert a schedule entry at some date within that period at which the phase or type of the well should switch. While the actual date of the switch is most likely known exactly to the operator, we assume for now that we have to work with the data as reported, meaning that a suitable approximate date must be set. Flownet will need to keep track of the history of each well.

Note that if separate wells are defined in an Eclipse schedule for the same physical well, these wells may not necessarily be defined at the same date.

Note also that schedule files have been encountered where initially for all wells dummy connections with all layers are defined using a single COMPDAT keyword entry with default values for the I and J well indices:
COMPDAT
'* ' 0 0 1 50 'SHUT' 1* 1* 0.15 /
/
The bottom_node perforation option available with Flownet does not consider re-definitions of the well connections at later times and will therefore always use the connection with the lowest layer in the model (50 in this example) to place the well node. Apart from the fact that these nodes are incorrectly placed, for wells with identical I,J indices specified in the WELSPECS keyword, this will create duplicate well nodes.

[olwijn]

A suggested solution approach:

1. Identify wells that are closer to each other than some threshold value. This would need to be based on similarity of either the full list of connections, or on similarity of the well nodes that would be created by FlowNet. These wells (and their schedules) will be 'merged' into a single, renamed, well unless they satisfy the criterion in point 2. (Comment: Wells that are re-perforated as part of a type conversion, or sidetracked, will most likely not have the same I, J indices listed in the WELSPECS keyword. These can therefore not be used to reliably identify all such wells in the schedule.)
2. If wells that should be merged by the criterion in point 1 are active simultaneously at any point in time (at the time resolution of the production data report, e.g. WAG wells), do not merge the wells (and keep schedules separate) but associate them with the same well nodes.
3. Create well nodes (single or multiple, depending on the perforation handling strategy) for the 'merged' wells.
4. Merge the schedules of the 'merged' wells into a single schedule with appropriate well type switches.

The ECLIPSE schedule may need to be reworked to remove any COMPDAT entries with default indices to avoid resulting complications for FlowNet.

[olwijn]

The identification of duplicate wells based on well nodes seems easiest. _well_connections in _from_flow.py returns a dataframe with wells and associated well node coordinates. This dataframe will ultimately need to be modified if wells are merged. The dataframe is return to _run_ahm.py, as is the dataframe with production data for all wells. With this combined information it should be possible to modify the 2 dataframes.

[olwijn]

An alternative, possibly easier, solution approach is the following: keep all well nodes, but when creating the network that connects them, use only the unique set of well nodes, associate each well node with a list of wells rather than one unique well only.