Treatment of duplicate wells about flownet

[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.