Time shift in FlowNet results compared to original case

[equinor]

Time shift in FlowNet results compared to original case

[olwijn]

There is an error in all FLOWNET times appearing in the SCHEDULE section, and also the START time is wrong. While the ECLIPSE times are all the first day of the month, FLOWNET assigns the last day of that month.

[olwijn]

There is a problem with the resampling/interpolation done on the dataframe entries (https://github.com/equinor/flownet/tree/master/src/flownet/data/from_eclipse.py:145). It results in dates that do no longer correspond to the report dates while the actual data are not interpolated to the new dates:

The offset is due to the pandas date/time convention in which 'M' refers to the end of the month. Use 'MS' to refer to the beginning of the month.

Another small error is introduced by averaging multiple values in one month. This can simply be removed:
df = df.resample(self._resample).interpolate(method="linear")

[anders-kiaer]

Nice! M vs MS is a good catch. There are two options: Either we always in the code transfers M to MS before giving it to pandas, or we keep the user in control of what is given (without any extra logic).

I'm leaning towards the latter, and simply change the example configuration files from using x to xS.

Do you want to make a ~two-line PR of your findings @olwijn and then I would say we can close this issue 🎉 🍾

[olwijn]

After running Flownet with the new changes I noticed that there is still one issue with well BR-P-5, which is producing from the start date.


The interpolation scheme produces a nan for the first month resulting in the well remaining shut for that month. Modifying the interpolation as follows fills in the missing value with its neighbouring value:
df = df.resample(self._resample).interpolate(method="linear", limit_direction="backward")

This may not be entirely correct ofcourse but is probably much better than missing 1 month of production.

[olwijn]

There are further subtleties in the timing of wells: if a well is opened in the ECLIPSE schedule at e.g. 1 JAN 2001, the simulator will report it's first non-zero value at the next simulator time step, which could be for example 1 FEB 2001 as in the example below for BR-P-1. This is the time at which the well is now activated in Flownet. The well is therefore opened one month too late.

We have direct information about the well opening date in the eclsum data if the WSTAT keyword has been set in the SUMMARY section of an ECLIPSE run. We also know, however, that the well must have been openened at the report date in the schedule that immediately preceeds the simulation time at which the first non-zero values are reported. A related issue is that currently in Flownet a well always gets a target prescribed that was valid for the previous simulation time step in the ECLIPSE model, so Flownet will always be one time step behind. This can be solved by shifting all production data dataframe rows up one step. This should only be done, however, for quantities that are used as targets in a Flownet simulation, not for quantities that are used as observations.

[olwijn]

There is still something strange happening in the dataframe resampling/interpolation:


I would assume that values at the new dates in the lower panel would lie between those of the neighbouring dates in the upper panel. This is not the case. Perhaps the best solution is to avoid interpolation altogether and simply use the dates in the dataframe directly. Subsampling of these dates may be useful if values are reported very frequently, but it seems best not to use the pandas resample functionality for this since it is not entirely clear what it is doing.

[olwijn]

The theoretically correct way to deal with the times (if they are extracted from an ECLIPSE run at least), is as follows. (1) Remove all resampling/interpolation and work directly with the ECLIPSE dates. (2) Assign values that are used as well targets for Flownet to the simulation step immediately preceding the date at which they are reported by ECLIPSE. So the values that are used as observations need to remain at the ECLIPSE dates. This requires that: (1) The dates preceding the first non-zero value for each well have to be retained in the pandas dataframe. This needs to be done in _production data in from_eclipse.py (this has been done already). (2) The observations are currently extracted from the schedule. If the schedule dates are shifted, they will end up at the wrong date. A better approach would be to extract the observations dircetly from the ECLIPSE dataframe. This would also be a first step towards facilitating the use of observations that are not created by ECLIPSE.