Peter Verveer
Peter Verveer
The Everest ConfigKeys class (not to be confused with the class of the same name in ERT) serves no purpose, it is essentially a list of constant definitions. That class...
**Issue** Everest does currently not monitor and handle constraint violations properly, in particular output constraints. Currently only the `optpp_q_newton` algorithm seems to monitor output constraint violations, via a merit function...
**Issue** The `auto_scale` keyword allows the user to specify controls in their usual physical units, and scaling is then handled by the optimizer. However, the scaled controls are passed to...
**Issue** Over time the configuration format of Everest has become inconsistent and more complicated than necessary. Specific examples: - Objectives use normalizations: `normalization` is used to specify a multiplication value,...
**Issue** Optimization results are currently stored in an SQLite database, which is used by Everest via a snapshot object to report and store results. This approach is not directly supported...
This PR adds support for multi-segment wells to the `WELTRAJ`/`COMPTRAJ `keywords. A yes/no option is added to `COMPTRAJ `and if it is set, the equivalent to `WELSEGS`/`COMPSEGS `will be generated...
The [equinor/everest-optimizers](https://github.com/equinor/everest-optimizers) repository has matured to a point that the algorithms should be made available to Everest. This requires exposing them to `ropt` as a plugin, which will make them...
The Everest storage currently stores an `is_improvement` flag with each batch. Some comments: - It is only used by everviz, which is slated to be removed - It stores a...