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, while constraints use scale, a divider. This is not consistent. Controls also use scale. Scaling would also be more natural for objectives, since one generally wants to divide by a know range.
In the optimization section it is currently possible to specify options and backend_options, one is a list of strings, originally used by Dakota optimizers, the other a dict, used by SciPy optimizers. With the pydantic-based parser these could easily be collapses in a single keyword (i.e. options), ropt does this internally already.
To use alternative optimization (or sampler) backends, the backend keyword is used to select the plugin that provides the desired algorithms. Recent versions of ropt do not requires this anymore, it sufficient to provide the algorithm name and ropt will search for the correct plugin. The backend keyword could be removed, the user does not need to know how/where the algorithm is implemented
The controls section as a type field. It is a required field, but is it used anywhere?
It would be desirable to update the configuration code to resolve these issues. These would be breaking changes. In the examples above the first (normalization) would be encountered by all users. The next two issues are much less likely to have been used extensively except by a few experienced users. We should consider deprecating all three, possibly maintaining support for normalization indefinitely.
Issue Over time the configuration format of Everest has become inconsistent and more complicated than necessary. Specific examples:
normalizationis used to specify a multiplication value, while constraints usescale, a divider. This is not consistent. Controls also usescale. Scaling would also be more natural for objectives, since one generally wants to divide by a know range.optionsandbackend_options, one is a list of strings, originally used by Dakota optimizers, the other a dict, used by SciPy optimizers. With the pydantic-based parser these could easily be collapses in a single keyword (i.e.options),roptdoes this internally already.backendkeyword is used to select the plugin that provides the desired algorithms. Recent versions ofroptdo not requires this anymore, it sufficient to provide the algorithm name androptwill search for the correct plugin. Thebackendkeyword could be removed, the user does not need to know how/where the algorithm is implementedtypefield. It is a required field, but is it used anywhere?It would be desirable to update the configuration code to resolve these issues. These would be breaking changes. In the examples above the first (normalization) would be encountered by all users. The next two issues are much less likely to have been used extensively except by a few experienced users. We should consider deprecating all three, possibly maintaining support for normalization indefinitely.