Remove the wells section of the config file

[oyvindeide]

** Edit by yngve-sk: ** The wells section should be removed, and forward models updated accordingly.

---

The wells section of the Everest config is a bit confusing, and we should review its usage, today it serves two purposes:

1. It triggers loading of summary vectors from the well names if summary data is loaded
2. It outputs the section as json to runpath, regardless of the section being provided or not

The data in this section is used almost exclusively by: https://github.com/equinor/everest-models/blob/main/src/everest_models/jobs/fm_drill_planner/cli.py, so it should perhaps be a part of the configuration of that forward model instead?

[roliveira]

I agree that the usage of the wells keyword and produced wells.json file is confusing.

• Making the content of the wells (or the exported wells.json) keyword as part of the drill_planner forward model input follows the same logic of the other forward models.
• Other forward models also contains information that is present in wells.json
• There is a forward model that gets injected to produce the wells.json file regardless of it being defined or not. It's an extra copy_file that creates wells.json at both optimization and simulation output :

$ cat ./simulation_folder/batch_1/geo_realization_0/simulation_7/copy_file.stdout.0
Copying file '/everest-spe-rsc-2025/data/simple/everest/model/everest_output/.internal_data/wells.json' -> 'wells.json'

$ find . -type f -name wells.json
./.internal_data/wells.json
./simulation_folder/batch_1/geo_realization_0/simulation_7/wells.json
./simulation_folder/batch_1/geo_realization_0/simulation_1/wells.json
# [...]

I also must point that two other things:

• The wells.json is sometimes used as a transactional file, being overwritten from forward model to forward model where every time it goes through a forward model it gets more information added to it.
• For a lot of the cases, the needed input for the forward models might be available from other the controls itself, from other files, like as is in the input/wells_readydate.json file, or from input/rate_constraints.yml file.
• Maybe some forward models might have been bypassing the wells.json and using their own repeated definitions of it, as it seems with the well_trajectory forward model: https://everest.readthedocs.io/en/latest/forward_model_jobs.html#id6

[tup1985]

• The wells.json is sometimes used as a transactional file, being overwritten from forward model to forward model where every time it goes through a forward model it gets more information added to it.

Upon a quick check on the list of available forward models, wells.json or a variation of it is still needed as input for: drill_planner, drill_date_planner, add_templates and well_constraints.

I see some redundancy with wells_readydate.json file. Could we get rid of one of them maybe?

[yngve-sk]

https://github.com/equinor/ert/issues/11723#issuecomment-3248760951

• Inferring summary keys from this section is not ideal. Because this section contains typically only optimized wells and not all of the wells in the simulation model. For proper analysis user typically needs to have access to simulation results of all wells in the simulation model. There is already a way to specify summary keys in forward models:

  • job: flow r{{eclbase}} results: file_name: r{{eclbase}} type: summary keys: '*'

• I think at least 2 forward jobs use the information in a generated well.json from this section. fm_drill_planner uses drill_time field to calculate drill dates (this could be moved to drill planner config file). And fm_drill_date_planner has it listed as input file.

[yngve-sk]

https://github.com/equinor/ert/issues/11723#issuecomment-3252818806

We thought a bit more about this with Slawek, and suggest the following:

• The forward models can derive the well names from the controls. Currently we already check the names against controls of the control type well_control, but that will not work in the forward models. Instead, they can identify the control group by name and retrieve the well names from the control names. We should not repeat the well names in the configuration of all the forward models.
• The drill_time information can go in the configuration of the forward models that use it, there are only one or two that need it.
• It seems drill_date may be unused, so that is a candidate for removal, if that is indeed the case.

[verveerpj]

Resolving this issue implies that the well_control keyword will not be used anymore by the config validation code. Since it is not used anymore it can be removed.

See also issue #11720

[tup1985]

Resolving this issue implies that the well_control keyword will not be used anymore by the config validation code. Since it is not used anymore it can be removed.

See also issue #11720

But that means we are left with only generic_control as a type of control, which is required but useless at this point. Would it be good to abolish the control.type altogether? (I have no idea of the effort required to remove this)

[verveerpj]

Resolving this issue implies that the well_control keyword will not be used anymore by the config validation code. Since it is not used anymore it can be removed. See also issue #11720

But that means we are left with only generic_control as a type of control, which is required but useless at this point. Would it be good to abolish the control.type altogether? (I have no idea of the effort required to remove this)

Yes, I should have formulated that more precisely: we should remove control.type entirely (well, deprecate first).

[verveerpj]

It is not clear which forward models need input files, which could have the wells specified in their own config, or even if both mechanism might be necessary. These changes would be either inconsistent between forward models, or unnecessarily complicated. Moreover, user impact would be significant.

The current approach of specifying a set of shared well data via the Everest configuration is not that bad. The install_data keyword does a similar thing: copy shared files to the run path. Currently the wells section in the Everest configuration does effectively the same: it creates a file in the run path with some shared content.

I propose to use install_data to provide the data that is now in the wells section.

This could be done in two different ways:

1. The user provides a wells.json file and installs it with install_data. This works without any modification of Everest or the forward models. It puts some extra burden on the user, which could be eased somewhat by supporting YAML files.
2. The install_data keyword is extended to allow specifying the file content inline, like this:

   - data:
      - { name: OP1 }
      - { name: WI1 }
     target: wells.json
   

   which would direct Everest to output a file wells.json with the given content. Note that this would be a generic mechanism for specifying shared data directly in the configuration.

Option 1 is already available now. Option 2 requires only minor extension of the Everest configuration code.

[tup1985]

It is not clear which forward models need input files, which could have the wells specified in their own config, or even if both mechanism might be necessary. These changes would be either inconsistent between forward models, or unnecessarily complicated. Moreover, user impact would be significant.

Parsing the list of available forward models, only the ones serving the drilling order applications need to infer the drilling time from the wells section of the config file. Those are drill date planner and drill planner jobs. Any other job requiring a json file with well information is using wells readydates file and builds upon that. And this is a shared file that is either symlinked or copied in the runpath.

I see well filter job, but I have no knowledge of its usage, or any current implementation that uses it.

Until any refactoring of the forward models to accept new inputs/formats, I think Option 1 is the most straightforward, as we already provide a similar file as a static input for various optimizations wells_readydates.json.

[verveerpj]

Removing the wells section does not only affect everest-models, it also affects the loading of summary data. Currently, the code requires the well section to do that. The only other way I see to derive those file names is to derive them from the control names. But that has two potential issues:

1. It requires the use of control.type to detect which controls represent wells. We would prefer to also remove control.type.
2. Could the forward model have wells that are not optimized? These would then not be detected, and no summary data loaded.

We need to discuss the following:

1. We should carefully look at everest-models and see if we can make it fully independent of the generated wells.json file. In my first attempt I found it a daunting task.
2. We should discuss how the loading of summary vectors is handled: how do we communicate what should be loaded if we remove both wells and control.type?

Meanwhile I am proposing to make the wells section optional for now. The wells.json can the be generated from the controls. This covers the cases where no additional information (drill_time) is needed and where loading of summary data for the controls that are optimized is sufficient (See PR #12007). The wells section remains available for other cases. This is not a long-term solution in the sense that it requires control.type.

[verveerpj]

The wells section is now optional, if not provided, a wells.json file will be generated from the controls that have the well_control type. It will contain only the names of those controls.

If you do not specify wells this has the following consequences:

1. You can not load summary vectors from wells that are not optimized, because these are not known.
2. You cannot specify extra information for the forward models. Currently this is only the drill_time key (drill_data was not used and is removed).

If you need one of the features above, a wells section must be specified to override the one that is generated from the controls.

We would like to remove the well sections altogether, and the two issues above need to be resolved:

1. We need a different way to derive the well names, so that the set of required summary vectors can be defined. I would propose to simply load the desired summary vectors for all wells. I assume it is possible to derive the well names from the file that contains the summary vectors.
2. The drill_time should be specified in the configuration of the affected forward models. That would be in line with how we generally specify configuration data for forward models.

If these two issues are resolved, the wells section can be removed. In that case a wells.json file does not need to be generated anymore.

Note: Apart from the drill_time issue, there may be forward models that depend on a wells.json file containing only the well names. If that is the case we should seek a different solution for those forward models. For instance, if only the wells are needed that are optimized, they can be derived from the file containing the control values.

[tup1985]

1.We need a different way to derive the well names, so that the set of required summary vectors can be defined. I would propose to simply load the desired summary vectors for all wells. I assume it is possible to derive the well names from the file that contains the summary vectors. 2.The drill_time should be specified in the configuration of the affected forward models. That would be in line with how we generally specify configuration data for forward models.

This sounds like a desired solution.

[verveerpj]

1. We need a different way to derive the well names, so that the set of required summary vectors can be defined. I would propose to simply load the desired summary vectors for all wells. I assume it is possible to derive the well names from the file that contains the summary vectors.

Question for other developers that have more experience with this: currently fields related to wells are selected in the ERT code for reading by names of the following form "FIELD_NAME:WELL_NAME". Would "FIELD_NAME:*" work to select all the wells?

[verveerpj]

Blocked by https://github.com/equinor/everest-models/issues/202