Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of auto-scaled controls in forward models #8814

Open
verveerpj opened this issue May 6, 2024 · 2 comments · May be fixed by #9932
Open

Handling of auto-scaled controls in forward models #8814

verveerpj opened this issue May 6, 2024 · 2 comments · May be fixed by #9932

Comments

@verveerpj
Copy link
Contributor

Issue
The auto_scale keyword allows the user to specify controls in their usual physical units, and scaling is then handled by the optimizer. However, the scaled controls are passed to the forward models without back-scaling. The forward models must be configured with the minimum and maximum values from the Everest configuration and rescale the controls themselves. This duplication, with the associated risk of errors, could be avoided if Everest scales the controls back to their original range before transferring the values to the forward model.

@oyvindeide
Copy link
Collaborator

oyvindeide commented Aug 29, 2024

For more contextual information, from (@verveerpj):

Issue
Recently auto scaling for controls has been added in the form of the auto_scale keyword. This keyword directs the optimizer to scale the controls between the minimum and maximum to a given range (default: [0, 1]), scales the initial values and the perturbation magnitudes accordingly, and transforms the input constraints to remain valid. This allows the user to specify the controls, such as rates in their usual physical units, which is much more user-friendly.

The scaled controls are passed to the forward models without re-scaling, i.e., the remain in the [0, 1] scale (or whatever target scale was specified). Currently, the forward models expect this range, and do a rescaling operation themselves. To be able to these, the forward models must be configured with the original scale. Currently, this means that the minimum and maximum values specified in the Everest configuration must be duplicated in some forward model configuration files.

Proposal
This duplication, with the associated risk of errors, could be avoided if Everest scales the controls back to their original range before transferring the values to the forward models.

Effort and risks

-The changes in Everest are minor.

  • The changes in the forward model are also likely minor, i.e., by removing scaling operations, with cave-at that more checking might be needed (see next points).
  • This change would need to be done in a backwards compatible way. If auto_scale is not supplied, the forward models may still need to perform the rescaling themselves. This would need to be specified somehow in the configuration of the forward model.
  • There is a risk that the user specifies auto scaling while configuring the forward models to do manual scaling, or the other way around.

Some thought would need to go into how to handle the backward compatibility and risks, some options are:

  • Make the rescaling option configurable in Everest. Disadvantage: more keywords, more complicated for the user.
  • Always rescale, and configure rescaling manually in the forward model, e.g., with a command line option. Disadvantage, more configuration in the forward model, less user-friendly.
  • Always rescale, and only scale manually in the forward models when the necessary range is specified in its configuration. More user-friendly, but with the risk that either Everest or the forward model will be configured incorrectly.
  • Improve the communication between Everest and the forward models so that the forward models can check if auto scaling is enabled or not (is this possible currently?)

@verveerpj
Copy link
Contributor Author

This is related to a newer issue that would resolve this with a broader solution: #9537

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants