{"id":19835154,"url":"https://github.com/equinor/everest","last_synced_at":"2025-05-01T17:33:00.799Z","repository":{"id":237686105,"uuid":"795038588","full_name":"equinor/everest","owner":"equinor","description":"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.","archived":true,"fork":false,"pushed_at":"2024-12-17T08:55:09.000Z","size":4392,"stargazers_count":11,"open_issues_count":0,"forks_count":10,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-04-05T11:13:20.946Z","etag":null,"topics":["optimization","python","scientific","simulation","uncertainty"],"latest_commit_sha":null,"homepage":"https://everest.readthedocs.io/","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/equinor.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"COPYING","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-05-02T13:14:03.000Z","updated_at":"2025-01-29T13:05:14.000Z","dependencies_parsed_at":"2024-08-20T10:20:51.071Z","dependency_job_id":"b7867fcb-b989-49be-b88c-e256ff6027b2","html_url":"https://github.com/equinor/everest","commit_stats":null,"previous_names":["equinor/everest"],"tags_count":12,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/equinor%2Feverest","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/equinor%2Feverest/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/equinor%2Feverest/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/equinor%2Feverest/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/equinor","download_url":"https://codeload.github.com/equinor/everest/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251914952,"owners_count":21664454,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["optimization","python","scientific","simulation","uncertainty"],"created_at":"2024-11-12T12:06:50.055Z","updated_at":"2025-05-01T17:33:00.792Z","avatar_url":"https://github.com/equinor.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Python](https://github.com/equinor/everest/workflows/Python%20package/badge.svg)](https://github.com/equinor/everest/actions?query=workflow%3A%22Python+package%22)\n[![Style](https://github.com/equinor/everest/workflows/Style/badge.svg)](https://github.com/equinor/everest/actions?query=workflow%3AStyle)\n[![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)\n\n# Everest™\n\n\u003e :warning: **The Everest project development has moved into https://github.com/equinor/ert,\n\u003e this repository is deprecated and is no longer maintained. All issues have been moved into\n\u003e the ert repository, and new issues must be created there.**\n\nThe primary goal of the Everest tool is to find *optimal* well planning and production strategies by utilizing 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.\n\n\n## Requirements\n\nPython version:\nEverest supports Python version 3.8, 3.9, 3.10, 3.11, 3.12\n\nIn order to build, test and run Everest, a number of Python libraries must be available.\n\nFirst make sure to install the required and test dependencies\n```bash\n    pip install . \"[test]\"\n```\n\nIn addition, the following libraries must be present in your environment\nFor details about the build process, see the web pages of each individual library\n\n* [everest-models](https://github.com/equinor/everest-models)\n* [OPM](https://opm-project.org/) (Optional)\n\n#### Everest-models\nGet source from [everest-models](https://github.com/equinor/everest-models)\n\n```bash\n    git clone https://github.com/equinor/everest-models\n    cd everest-models\n    pip install . --upgrade\n```\n\n#### OPM (Optional)\n\nRead documentation at\nhttps://github.com/OPM\n\n## Testing\n\nSome tests require access to the `/project/res` folders in the Equinor internal network. If you don't have access to that folder, you have to `export NO_PROJECT_RES=1` so that those tests will be skipped.\n\nTests can be executed with\n```\npython -m pytest -m \u003ctest_category\u003e\n```\nwhere `\u003ctest_category\u003e` must be replaced by one of the following categories:\n- `ui_test` contains all the tests related to the user interface\n- `integration_test` contains self-contained integration tests (the above installation should be sufficient for them to pass).\n- `simulation_test` requires a more complete setup and among others requires the job `SYMLINK` to be known to _everest_ as well as access to `/project/res` in Equinor (the later is to be changed soon).\n- `redundant_test` test that covers portions of code already covered by other tests. They are regularly run on our CI system\n\n\n\n## The optimization process\n\nThe following is a brief explanation of how Everest works. It is inaccurate and incomplete, but it is hopefully a good starting point.\n\nEverest is designed for finding local maxima of functions $y=f(x)$ where the _variables_ (a.k.a. _controls_) $x$ are properties of wells (such as the date a well is drilled, the position of points along its path. etc.), while the objectives $y$ are typically quantities measured over a long period of time (such as the the Net Present Value, CO2 emissions, etc.).\n\nAn optimization problem must be specified using an _Everest config file_. The optimization part is handled by the [ropt](https://github.com/TNO-ropt/ropt) package, the computation of the objectives is handled by [ert](https://github.com/equinor/ert).\n\n#### Optimization\nThe actual robust optimization workflow is implemented by the `ropt` package, which builds on standard optimization algorithms to implement robust optimization strategies. By default `ropt` provides only algorithms from the SciPy package as its optimizer backend, but Everest by default installs a plugin to support gradient-based optimization algorithms from the Dakota package, e.g. Newton and quasi-Newton methods.\n\nBased on an initial assignment of the control variables $x_0$, `ropt` starts a backend optimization algorithm, which asks `ropt` to provide the values of the function $f(x_0)$ and its gradient $f'(x_0)$. Once the values are provided, the optimization algorithm determines a new set of control variables $x_1$ with a corresponding function value $f(x_1)$. If $f(x_1) \u003e f(x_0)$, $x_1$ becomes the current maximum, and the entire process is repeated until certain exit conditions are encountered.\n\nThe role of `ropt` is to implemented robust optimization functionality on top of the backend algorithm, among others this includes:\n- Maximization: Most standard optimization algorithms solves minimization problems. `ropt` take care of negating all the values so that a maximization problem is solved instead.\n- Robust function evaluation: the function to evaluate usually derives from an ensemble of different geological models (realizations), in order to take uncertainty into account. `ropt` asks `ert` to evaluate each realization and calculates a single function from the set of calculated function values.\n- Gradient estimation: in most of the cases we are targeting, it is impossible to provide the exact value of the function gradient. When a gradient is needed, `ropt` generates several perturbations of the controls $x_i = x + \\delta_i$ and asks ert to compute all the functions $y_i=f(x_i)$. Once the results are available, ropt determines an estimate of the gradient by performing a linear regression of the values $(x_i, y_i)$.\n- Multiple objectives: `ropt` supports optimizing several objectives at once.\n\n#### Function computation\n`ert` takes care of computing function values for the ensemble of geological models. `ert` knows nothing about the problem to be solved, its main responsibility is to execute a _forward model_, on all the geological realizations. The forward model is given by a sequence of _jobs_ that the user must provide in the Everest configuration file.\n\nNOTE: since the most expensive job in a forward model is usually a reservoir simulation, the execution of a forward model is often called a _simulation_, especially when talking about _batches_ (see below).\n\nLet's look at an example: assume the config file contains the specifications for a group of control variables called `my_wells` and two objectives called `npv` and `co2_emissions`.\n`ert` creates a dedicated folder for executing the forward model, and copy/links all the necessary files (the geological realization) into it. The folder is located deep down in the _simulation folder_ specified in the config file. The current assignment of the control variables is written to the file `my_wells.json` located in that folder. A forward model typically begins with some setup operations based on `my_wells.json`, then runs a reservoir simulation ([Eclipse](https://www.software.slb.com/products/eclipse/simulators) or [flow](https://opm-project.org/?page_id=19)), followed by some post-processing and the eventual creation of the files `npv_0` and `co2_emissions_0`. Each of those files must contain a single line of text, which is the desired function value.\n\n\nRequests from `ropt` to `ert` are grouped into batches. A batch can include simulations related to evaluating the function, the gradient, or both. The number of simulations in a batch is often a good indication of what is going on. Let `real_num` be the number of geological realizations and `pert_num` the number of perturbations ropt generates for computing  a gradient. Then:\n- A batch executed for evaluating the function $f(x)$ has exactly `real_num` simulations\n- A batch executed for evaluating the gradient $f'(x)$ has exactly `real_num * pert_num` simulations\n- A batch that evaluates both the function, and the gradient has `real_num + real_num * pert_num` simulations\n\nNotes:\n- By setting the `speculative` option, all the batches have both function and gradient evaluations\n- Simulations in a batch have an incremental id. If a batch has both function and gradient evaluations, the first `real_num` simulations are the ones used for the function evaluations\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fequinor%2Feverest","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fequinor%2Feverest","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fequinor%2Feverest/lists"}