OPM / opm-core

I just ran SPE1 in parallel. In this case the situation occurs that the last (second of two) wells has no connections and memory bounds are violated in

opm-core/opm/core/simulator/WellState.hpp

Line 134 in ce78dc5

const int first_cell = wells->well_cells[wells->well_connpos[w]];

The problem is that wells->well_connpos[1] is 1 and that is also the size of the wells->well_cells array.

As I do not have the complete overview on the well treatment I would like to get some input here. Shall we either disregard wells with no connections completely here or treat them like a wells for which well_controls_get_current_type(ctrl) == BHP holds?

BTW this feels like a Déjà vu

Same issue here:

opm-core/opm/core/simulator/WellState.hpp

Line 94 in ce78dc5

const int first_cell = wells->well_cells[wells->well_connpos[w]];

Not sure whether this handled correctly for multi segment wells.

Even for sequential runs we could have this situation if the last well is shut and all completions are in non-active cells.

BTW this feels like a Déjà vu

Not again...?

Joke aside, I think we should disregard wells with no connections completely. The initialization code makes no sense for such wells, and should not be needed as the wells are not connected in any way with the rest of the problem.

I am not quite sure what happens to such wells in the simulator though -- I thought that at some point such wells would be treated as shut and totally ignored, but that may not be 100% correct. In any case, initializing their bhps with a simple default (1 atmosphere?) should not do any harm as it should never interact with the rest of the problem. A slightly more sophisticated way may be to see if the connection-less well has a bhp control, and use that limit (currently that is only used if bhp is the current active control).

I guess this is connected to output. If we totally neglect them then they will not appear there (no well curves).

There also might be cases where perforations appear at a later stage or vanish. Therefore a well with no valid perforations might have some at another point in the simulation.

Wells can shut, open, shut again etc. so if they participate in the simulation can change. The point about how output treats this is a good one: should we arbitrary insert zeros for bhps of shut wells in the output for example? Perhaps @joakim-hove can shed a little light on this issue?

I will repeat myself here, too (sorry for the noise).

The problem I experienced was caused by buggy opm-grid loadbalancing code that was never in master.

Still there are situations where we can have open wells which have open wells according to eclipse but all of them get closed by the simulator because they are on inactive cells or the Limiter DynamicListEconLimitedtells it to shut them in WellsManager::createWellsFromSpec. This situation has to be handled somehow

Should be fixed with the merge of #1067

WellState::init has memory problems