Improve ease of specifying optimization controls

[verveerpj]

Is your feature request related to a problem? Please describe.
Currently optimization controls values are specified in a normalized form, which puts the burden on the user to transform initial values and other related properties to the target scale. In addition, the forward models must do the reverse scaling as they generally require the values in their native units. Everest does support some automatic scaling, but this is not fully supported yet by the forward models.

In some cases the numerical values of the controls may not even be of interest to the user and may even depend on the backend optimizer. For instance, in well swapping problems the optimizer may require priority values to establish an ordering. The user is not interest in the numerical values, but rather in the ordering of the controls. Gradient based optimizer may require continuous variables normalized to a certain range, while discrete optimizers may require integer values. These implementation details could be hidden to the user, who would only specify an initial well ordering and finally receive an optimized ordering.

Describe the solution you'd like
The user should be able to specify control properties in a natural way. This includes providing values in their natural scales/units, but possibly also in other non-numerical forms, such as an ordering. Everest should translate these to the appropriate numerical representation internally, perform optimization using the transformed values and present the results after transforming them back to the natural representation.

Describe alternatives you've considered
N/A

Additional context

• This feature strongly depends on the type of application, hence multiple options are needed. Some, such as linear scaling and priority values may be generic and could be built-in. Others may be much more application-specific and a plugin-based approach may be called for.
• The forward models may need to be aware of the transformations that need to be done. Some transformations may occur in Everest, others possibly in the forward models. Communication between Everest and forward models may be needed beyond what is done now.
• Linear scaling is already supported by ropt and used by Everest, but not fully supported by all models. There is still code needed to complement the operations done by ropt both in Everest and in the forward models.
• The controls section in the Everest configuration has a type key that is currently not used. It could be repurposed to specify what type of transformations need to be done.

[verveerpj]

This may also resolve this issue: #8814

[verveerpj]

Assigned it to me, but left it in backlog to first sort out more urgent things.