equinor / fmu-ensemble

Python objectification of reservoir model ensembles left on disk by ERT.
GNU General Public License v3.0
12 stars 19 forks source link

Relaxed on requirement for parameters.txt #226

Open alifbe opened 2 years ago

alifbe commented 2 years ago

In some cases, we run prediction using restart file from other ensembles. For example in Drogon, we have a prediction run that is based on iter-3 of automatic history matching (AHM) model. For these cases, there won't be parameters.txt in the RUNPATH. FMU Ensemble will not read the data from those cases and causing crash in Webviz plugin StructuralUncertainty.

I have tried to put an empty parameters.txt and the plugin seems to work fine.

So, I am suggesting to relaxed the requirement for parameters.txt in this code

https://github.com/equinor/fmu-ensemble/blob/d63a3807cf85fba15c898c38fa42e9d2a6aa3d56/src/fmu/ensemble/ensemble.py#L410-L422

asnyv commented 1 year ago

Sorry that you haven't gotten any response on this.

From the code you refer to, it seems like an empty dataframe is returned, and not that it crashes. That makes sense to me: no data -> blank output? the alternative is to maybe still add the realization column and nothing else. But based on the attached code, this seems to me like a problem that likely needs to be resolved in the webviz plugin you refer to

asnyv commented 1 year ago

But: Even for restarts / prediction runs it is generally recommended to add uncertainty. 1) It is often useful to transfer the parameters from history into prediction to see if you can get some insight into which AHM parameters that affect the predictions, considering predictions are what really matters (the history is water under the bridge) 2) You generally have other factors that are uncertain for the predictions, e.g. minimum flow in wells and pipelines, risk factors for sand / scale issues or other things that affect productivity, capacity limitations on water handling, timing of future projects, productivity of new wells and so on.

alifbe commented 1 year ago

Ideally, it will be great if it loads the result per realization into the data frame instead of returning empty data frame because these data are needed for the plugin.

https://github.com/equinor/fmu-ensemble/blob/d63a3807cf85fba15c898c38fa42e9d2a6aa3d56/src/fmu/ensemble/ensemble.py#L486-L520

In fmu-drogon, we have created a forward model that transfer the parameters.txt from history (https://github.com/equinor/fmu-drogon/commit/a7aa6d5f37a15ce68c28974fe2cf29fd1f61bfca), but I just think it will be great that we can still support the runs that are already performed (without this new forward model)