Do not compute WellState::numPhases

[blattms]

but store it during initialization and reuse it afterwards. Previously it was computed by dividing
the size of the bhp_ array by the number of wells. This crashed if there were no wells present/active, e.g. when writing the report step.

Closes OPM/opm-simulators#731

[blattms]

Do not merge yet. I am running into other problems now.

[blattms]

With the recent commit it works for me.

Please be aware that developers are allowed to change the welllRates and bhp vectors. That might change the number of phases. Maybe we should only use numPhases_ as fallback if there are no wells present?

[atgeirr]

I don't think this will work, as numPhases_ is not initialized unless you have a Wells* (which I believe is null in the no-wells case).

Edit: maybe simply adding a constructor argument is the best?

[blattms]

I beg to differ: It does work for the current OPM as numPhases() will be called but the result never used if there are no wells. (Norne and SPE cases run through).

The problem concerning the extra constructor argument is that the usual call sequence is:

WellState well_state;
well_state.init(wells, state);

Retrieving the number of phases from eclipse state in addition seems like extra work.

Anyway, I will post a competing PR to this one in a minute.

[blattms]

Wrong usage might still result in using a wrong number of phases and will lead to bugs that are hard to find. I prefer to get a floating point exception that make debugging much more easy. Closing...

[atgeirr]

Was this closed because the PRs in opm-simulators make sure this is never called without wells? Or did I misunderstand the relations here?

[blattms]

Yes it was closed as OPM/opm-simulators#742 can handle the problem. Furthermore getting a floating point exception when used improperly is much easier to debug than hunting wrong indexing in arrays because of a bogus number of phases.