Kai Bao

For clarification, the 16-day limitation was imposed to obtain comparable results for the targeting field case at that time. It was not due to stability reason. The commercial simulator typically...

> We may also want to consider to use a smaller value for target newton iterations This will reduce the time step more quickly due to target newton iteration numbers,...

With more cases we have seen now, we should try to remove the 16 days constraints in some way.

16 days constraints were introduced back then for some cases (group control related), the reference running were performed with much smaller time steps (smaller than 16 days due to their...

jenkins build this please

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.

jenkins build this please

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

The assertion failures are from the following code, ```c++ 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...

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