PROCESS is a systems code at UKAEA that calculates in a self-consistent manner the parameters of a fusion power plant with a specified performance, ensuring that its operating limits are not violated, and with the option to optimise to a given function of these parameters.
Successive evaluations of all models for the same optimisation parameter vector produce changing outputs; evaluating the models is not idempotent. As single model evaluations are current being used, this means that some values (and their gradients) being input to the solver during an optimisation and the final results may not be accurate, as they would change on successive evaluations of the models. The fraction of all output variables in Process with a coefficient of variation $> 1.0\times10^{-6}$ after successive model evaluations at the same optimisation parameter vector is shown below.
It's likely this is due to dependencies in the models being out-of-sync with the call order, and therefore some calculations will use a value from the previous evaluation, as the current one is not yet available. This could possibly be improved by re-ordering the model calls/calculations, but it's equally possible that this "out-of-sync-ness" is inherent in the problem definition.
By evaluating the models multiple times, the values converge, as in the figure. This convergence should be assured before inputting values/gradients into the solver, and again before outputting the final result.
Successive evaluations of all models for the same optimisation parameter vector produce changing outputs; evaluating the models is not idempotent. As single model evaluations are current being used, this means that some values (and their gradients) being input to the solver during an optimisation and the final results may not be accurate, as they would change on successive evaluations of the models. The fraction of all output variables in Process with a coefficient of variation $> 1.0\times10^{-6}$ after successive model evaluations at the same optimisation parameter vector is shown below.
It's likely this is due to dependencies in the models being out-of-sync with the call order, and therefore some calculations will use a value from the previous evaluation, as the current one is not yet available. This could possibly be improved by re-ordering the model calls/calculations, but it's equally possible that this "out-of-sync-ness" is inherent in the problem definition.
By evaluating the models multiple times, the values converge, as in the figure. This convergence should be assured before inputting values/gradients into the solver, and again before outputting the final result.