search

equinor / everest

The primary goal of the Everest tool is to find optimal well planning and production strategies by utilising an ensemble of reservoir models (e.g., an ensemble of geologically-consistent models). This will enable robust decisions about drilling schedule and well placement, in order to achieve results of significant practical value.
https://everest.readthedocs.io/
GNU General Public License v3.0
5 stars 10 forks source link

Validation and documentation of generic optimizer options #76

Open oyvindeide opened 2 weeks ago

oyvindeide commented 2 weeks ago

We need to make sure Everest has a way of validating the generic options for the optimizer section of the config, including the generic options that are passed to the the underlying optimizer. This probably requires implementation of some plugin functionality where the installed optimizers provide their schema.

verveerpj commented 2 weeks ago

This might be a difficult task in general, simply because there are too many possible options. The optimizers are provided via a plugin mechanism in ropt, so there may be an arbitrary set of optimizers, and each can have multiple (sometimes many, sometimes changing) options. Same issue exists with documenting those options. This is the reason that ropt does not implement documentation and validation of optimizer options. It is assumed that the user will consult the documentation of the optimizer and that any validation would occur when the optimizer would be called. Since ropt is intended to be a generic backbone for implementing optimization applications (i.e. Everest) without limiting the choice of optimizer/options that should probably stay like that.

However, that is indeed less ideal for end-user applications like Everest, for instance there have been requests to document the Dakota options in Everest itself. If we want better validation/documentation in Everest, we will probably have to make a choice for the optimizers and options that are supported. That has the danger of locking the users into those optimizers/options which could inhibit more innovative use, so there should probably be some option to "escape" the validation when needed.

The implementation of this could be in Everest directly without any changes in the optimizer plugins, or we could add some schema mechanism to ropt and the plugins. The latter is a bit more work, but it would keep Everest more agnostic of the optimizer implementation.