Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add totals as measurements #284

Merged
merged 13 commits into from
Jan 4, 2021
Merged

add totals as measurements #284

merged 13 commits into from
Jan 4, 2021

Conversation

olwijn
Copy link
Collaborator

@olwijn olwijn commented Dec 7, 2020

Insert a description of your pull request (PR) here, and check off the boxes below when they are done.


Contributor checklist

  • 🎉 This PR closes Use cumulative production as observations #266.
  • 📜 I have broken down my PR into the following tasks:
    • Provide support for cumulative rates as observation data
    • Tested the use of cumulate rate data at only the final time
  • 🤖 I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR.
  • 📖 I have considered adding a new entry in CHANGELOG.md.
  • 📚 I have considered updating the documentation.

@@ -187,6 +187,9 @@ def _calculate_wconhist(self):
oil_rate=value["WOPR"],
water_rate=value["WWPR"],
gas_rate=value["WGPR"],
oil_total=value["WOPT"],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recalculating could potentially mean that one doesn't have to supply this at all.

@@ -153,7 +156,7 @@ def _production_data(self) -> pd.DataFrame:
* Improve robustness pf setting of Phase and Type.

"""
keys = ["WOPR", "WGPR", "WWPR", "WBHP", "WTHP", "WGIR", "WWIR", "WSTAT"]
keys = ["WOPR", "WGPR", "WWPR", "WOPT", "WGPT", "WWPT", "WBHP", "WTHP", "WGIR", "WWIR", "WGIT", "WWIT", "WSTAT"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're adding WGIT and WWIT here but not in the documentation a few lines earlier and neither are they added in src/flownet/config_parser/_config_parser.py. Is that intentional?

Should you read those values at all? You can reconstruct the cumulative at any given date by calculating the cumulative sum over the rates (this would also be easier to use later on in other data sources)? Or do we expect big differences based on differences in reporting steps?

Copy link
Collaborator

@olelod olelod Dec 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: Sorry, you are only referring to injection here @wouterjdb. Then you may be right.

The rates are instantaneous, and depending on the report step length we can get a quite different result reading the actual cumulative volumes and calculating them from rates. Over the years when doing uncertainty studies I have always calculated average yearly or monthly rates from cumulative volumes - for history matching purposes I guess the instantaneous rates are important - what I am saying is that we may need to import both then.

Copy link
Collaborator Author

@olwijn olwijn Dec 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will only be using WGIT and WWIT if we prescribe BHP instead of the well rates during the history matching. Although I am not sure if there are cases where you would prefer to do that, I thought it would be good for completeness to just add them. I forgot about adding them to src/flownet/config_parser/_config_parser.py.

@@ -136,6 +136,51 @@ def _to_abs_path(path: Optional[str]) -> str:
},
},
},
"WOPT": {
Copy link
Collaborator

@olelod olelod Dec 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When adding WOPT (or WGPT or WWPT), should we allow for also adding WOPR (or WGPR or WWPR)? Conditioning on both rates and cumulatives i guess is kind of a messy thing with all the correlation going on. Should we add a check in the config_parser to make sure both are not defined?

Update: Let's leave it for now and add an issue on it so we don't forget about it completely

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will make a new issue suggesting this and add an item to the CHANGELOG

@olelod olelod self-requested a review December 18, 2020 09:27
Copy link
Collaborator

@olelod olelod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should also add to the CHANGELOG that it is possible to condition on cumulatives now. Other than that it looks good to me!

@olelod olelod self-requested a review December 18, 2020 10:33
Copy link
Collaborator

@olelod olelod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@olelod olelod merged commit d1c534a into equinor:master Jan 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use cumulative production as observations
3 participants