not turning off injector because of defaulted rates.

[GitPaean]

it must be a limit to turn it off. The old implementation make it impossible to have a injector with only bhp control.

And also, in my understanding, for well control, it always is the time or TSTEP after the WCON* keywords. Please correct me if I am wrong. I saw things very differently test cases many times and I always got confused.

[GitPaean]

jenkins build this please

[atgeirr]

And also, in my understanding, for well control, it always is the time or TSTEP after the WCON* keywords. Please correct me if I am wrong. I saw things very differently in many test cases and I always got confused.

It is indeed like this, the controls apply to the time step following the control keyword. You are right in that there are several tests which end with a control change (which never would be used). @joakim-hove are these tests like that specifically for testing that corner case?

[joakim-hove]

And also, in my understanding, for well control, it always is the time or TSTEP after the WCON* keywords. Please correct me if I am wrong. I saw things very differently test cases many times and I always got confused.

This is confusing - to be honest I got confused right by trying to explain it. Maybe there actually is a fine nuance between the DATES and the TSTEP keywords? The DATES keyword should be interpreted as this:

-- The simulator is humming along with unmodifed controls. Then suddenly it encounters a DATES
-- keyword. OK - time to gather forces, make some output and so on:

DATES 
   10 NOV 2017 /

WCONHIST              -- This well rate adjusment happens in "zero time" and will apply
   .....                         -- for the simulator until the next DATES keyword.
/

DATES 
   10 DECEMBER 2017 /

it always is the time or TSTEP after the WCON* keywords.

Yes:

1. You set the rates with WCON*
2. You encounter the TSTEP keyword which means you should simulate for 'X' days with unmodified controls, and then stop for output.

[joakim-hove]

you are right in that there are several tests which end with a control change (which never would be used). @joakim-hove are these tests like that specifically for testing that corner case?

That is probably just because we have been confused as well.

[joakim-hove]

I will get back to your actual fix; must admit I did not fully understand - some more text?

[GitPaean]

I will get back to your actual fix; must admit I did not fully understand - some more text?

For an injection well, when there is not rate input, it means there is not rate limit. For the WellInjectionProperties, by default, we get a zero value for the rate.

The original code basically says that we have a zero value for the rate, crossflow is not allowed for the well, it does not make sense, let us remove this well.

The new code does it a little differently, we have a zero rate limit for the well, crossflow is not allowed for this well, let us remove this well.

Basically, the value of the WellInjectionProperty should only works as a limit, when we have that control type. When there is not rate control type, the rate value of the property does not matter.

In the long run, maybe we should introduce a function called rateLimit(), with the function, we check if we have a rate control type, then check the value. When there is no rate control type, basically it means there is not rate limit, we return a biggest possible value instead of returning a zero value.

[GitPaean]

WCONHIST              -- This well rate adjusment happens in "zero time" and will apply
   .....                         -- for the simulator until the next DATES keyword.
/

DATES 
   10 DECEMBER 2017 /

I agree. Basically, if there were not DATES here, the things set in WCONHIST will not take affects for the simulation, or take affects for not time. (It might matters for final output based on what you want actually. )

[joakim-hove]

In the long run, maybe we should introduce a function called rateLimit(), with the function, we check if we have a rate control type, then check the value. When there is no rate control type, basically it means there is not rate limit, we return a biggest possible value instead of returning a zero value.

I agree - the Production and Injection property objects are certainly in the category: not-so-succesfull-abstractions

[joakim-hove]

jenkins build this please

[GitPaean]

I changed the marking of the report step in SCHEDULE_WELLS2 a little bit to make it easier to count. It looks like agree well with the counting in the testing code and potentially make the fixing test related to this file easier. @joakim-hove , how do you think?

I did not push it forcedly to keep the commit to make it easier to remove if needed. And it is also kind of different task from the previous commit.

[GitPaean]

jenkins build this please

[GitPaean]

Basically, the change to the file SCHEDULE_WELLS2 means all the control keywords are always combined with the TSTEP or DATES afterwards to form report steps. If there is not TSTEP or DATES afterwards, the control keywords will not work for the simulation.

[joakim-hove]

jenkins build this please