Align the terminology of realization between everest and ert

[oyvindeide]

Currently the everest has the model section of the config:

model:
  realizations: [0, 1, 2]

however internally in everest these become geo_id, while everest also sometimes refer to them as realizations. However when running simulations, everest will spawn simulations, which are also referred to as realizations. These last ones are more in line with how ert relates to the variable realizations.

Sometimes these are of str type, and sometimes int. This should also be aligned.

List of occurrences that should be streamlined/clearly differentiated:
sim_id
simulation_id
geo_id
geo_realization
realization
It should (ideally) be clear if something refers to a simulation, geo-realization, or "ert realization", either through variable naming or comments to clarify.

[verveerpj]

A few points;

• The realizations that Everest uses in the optimization are specified in the Everest configuration in the model.realizations field as a list of integers. It is not clear to me what these really are. I understand that these derive from the concept of a geo_id, but are they really ID's? It seems like that when I inspect a case on disk, for instance the egg example, where you see that realizations are stored in folders with names of the form realization-#. But could it be that they are really indices and used like that? For instance, internally we have in ERT the concept of active realizations represented by an array of bools, so there we are probably using the realization integer as an index.
• The mixed use of integers and strings was confusing for me. In ropt I ended up not using realization ID's at all. There, realizations are just represented by an array of weights, which basically defines how many realizations there are, and which weight each has. It is up to the evaluator in Everest to assign the right geo realizations when running the forward models. ropt will just provided indices of the realizations, which can be used to index into a list of realizations. Currently ropt also provides a list of realization names in its config and currently that is used to find the realizations in the evaluator. That list is actually the same as the model.realizations field of the Everest config and we should use the latter instead. I plan to do a another refactoring round beginning next year to fix that. (And minimize the use of ropt config in the evaluator in general).
• I am not keen on names of the form geo_*, we should aim to make Everest a bit more generic for use in applications where that does not make sense (i.e. wind, solar, etc.)
• A big source of problems for Everest is that it seems that in ERT a realization seems to equate to a single forward model run, while in Everest, a single realization may consist of multiple forward module runs (for instance, multiple perturbations). Hence the awkward mapping of simulation onto realization in ERT, to coerce the ERT ensemble evaluation into running all those simulations in a single batch. Ideally I would like the ERT evaluator not to use the terms ensemble and realization, but something more neutral, but I guess it is probably too much to ask for that...