OPM
[testing] testing whether defaulted zero thp has ever been used.
The concern regarding this PR is that 0.0 thp limit does not mean no thp limit. So if not used properly, it might have some undesirable consequence.
From the jenkins failures, it looks like that we might use the controls.thp_limit while the constraint does not exist.
flow: /var/lib/jenkins/workspace/opm-simulators-PR-builder@2/opm/simulators/wells/WellBhpThpCalculator.cpp:85: double Opm::WellBhpThpCalculator::getTHPConstraint(const Opm::SummaryState&) const: Assertion `controls.hasControl(Well::ProducerCMode::THP)' failed.
Will investigate this.
The assertion failures are from the following code,
const double thp_limit = well_.getTHPConstraint(summary_state);
ws.thp = this->calculateThpFromBhp(rates, ws.bhp, rho, alq, thp_limit, deferred_logger);
somehow, due to WVFPDP, we need the thp_limit to do something, while calculateThpFromBhp should not need thp_limit. Moreover, thp_limit does not exist sometime, a zero value will be used there.
The intention was to make sure double WellBhpThpCalculator::getTHPConstraint(const SummaryState& summaryState) const does not return any undefined THP limit value. (no THP constraint defined and return some value (most likely zero from the default value as a member variable)).
No intention to change any implementation and result.
Will clean up and propose a PR.