clean-up

Author: StephanDeHoop

Diff for: docs/everest/development.rst

@@ -59,20 +59,23 @@ long as the optimization process is running.
 EVEREST vs. ERT data models
 ===========================
 EVEREST uses ERT for running an experiment. Whenver an EVEREST `experiment` is ran, `everserver` creates an `EverestRunModel` based on the
-`ErtConfig` (obtained from `EverestConfig`). The `ErtConfig` requires an `EnsembleConfig`. Here we map EVEREST `objectives` (i.e., objective functions)
-and `constraints` to `responses` in ERT using `GenDataConfig` (stored in `EnsembleConfig.response_config`).
-In `everest_to_ert_config` we map all the EVEREST `controls` to ERT `parameters` using `ExtParamConfig` (stored in `EnsembleConfig.parameter_configs`).
-Then in `EverestRunModel._forward_model_evaluator` (used as evaluator by the external optimization library `ropt`) we create a local storage for the `batch` (i.e., `ensemble`),
-link to the current `experiment`, and setup up `simulations` for a set of `controls`.
-
-All the forward models in the `batch` are then evaluated in ERT using `EverestRunModel._evaluate_and_postprocess` (and in turn `BaseRunModel.run_workflows`)
-which uses the `EnsembleEvaluator` for execution. After ERT writes to `simulation_results` and stores results in the `LocalEnsemble` (i.e., storage)
+`ErtConfig` (obtained from `EverestConfig`). The `ErtConfig` requires an `EnsembleConfig` where EVEREST `objectives`
+and `constraints` are mapped to ERT `responses` using `GenDataConfig` (stored in `EnsembleConfig.response_config`).
+In `everest_to_ert_config` all the EVEREST `controls` are mapped to ERT `parameters` using `ExtParamConfig`
+(stored in `EnsembleConfig.parameter_configs`). Then in `EverestRunModel._forward_model_evaluator` (used as evaluator
+by the external optimization library `ropt`) a local storage is created for the `batch` (i.e., `ensemble`),
+linked to the current `experiment`, and setup up `simulations` for all sets of `controls`.
+
+All the forward models in the `batch` are then evaluated in ERT using `EverestRunModel._evaluate_and_postprocess`
+(and in turn `BaseRunModel.run_workflows`) which uses the `EnsembleEvaluator` for execution. After ERT writes
+to `simulation_results` and stores results in the `LocalEnsemble` (i.e., storage)
 these results are then gathered in the forward model evaluator (called by `ropt`) and feedforward into the optimizer using
-`EverestRunModel._gather_simulation_results` (i.e., reading the `.parquet` files generated by ERT). Every set of forward model executions for a single
-set of inputs (`controls`) and outputs (`objectives` / `constraints`) constitutes an ERT `realization` in the ERT queue system; denoted in EVEREST as `simulation`.
+`EverestRunModel._gather_simulation_results` (i.e., reading the `.parquet` files generated by ERT). Every set of
+forward model executions for a single set of inputs (`controls`) and outputs (`objectives` / `constraints`)
+constitutes an ERT `realization` in the ERT queue system; denoted in EVEREST as a `simulation`.
 
-Since EVEREST optimizes a set of `controls` and assumes static (i.e., unchanging) `realizations`,  there is a distinction between `unperturbed controls`
-(i.e., current `objective function` value) and `perturbed controls` (i.e., required to calculate the `gradient`).
+There is a distinction between `unperturbed controls` (i.e., current `objective function` value) and
+`perturbed controls` (i.e., required to calculate the `gradient`).
 Furthermore, when performing robust optimization (i.e., multiple static `realizations`) a `batch` contains a
 certain number of `realizations` (denoted by `<GEO_ID>`) and each `realization` contains a number of `simulations`
 (i.e., forward model runs). These `simulations` are forward model runs for either `unperturbed controls` and/or