search

idaholab / HERON

Holistic Energy Resource Optimization Network (HERON) is a modeling toolset and plugin for RAVEN to accelerate stochastic technoeconomic assessment of the economic viability of various grid-energy system configurations, especially with application to electrical grids and integrated energy systems (IES).
Apache License 2.0
24 stars 38 forks source link

[DEFECT] Tighter pyomo optimization tolerance option #67

Closed wanghy-anl closed 1 year ago

wanghy-anl commented 3 years ago

Defect Description

I developed a validator for a 3-unit system composed of Balance of Plant (BOP), Secondary Energy Source (SES) and Thermal Energy Storage (TES). Under some situations the dispatcher cannot observe the validation constraints identified in a previous solve attempt. I outputted the dispatched value (curr) from pyomo and the constraints (V1) calculated by the validator when validation concerns are raised, see the docx file attached. Dispatcher Issue.docx

What did you expect to see happen?

I am expecting that on Attempt 4, unit = TES, t=12, the dispatcher can issue a "curr" value lower than the upper constraint (V1= 501003.691) found in Attempt 3.

What did you see instead?

On Attempt 4, 5, ..., 101, unit = TES, t=12, the dispatcher never observe the upper constraint (V1= 501003.691) found in the previous solve attempt. In fact, only the upper constraint (V1= 501004.074) found in Attempt 2 is observed. The gap between “curr” and “V1” in Attempts 4 and beyond remain the same 0.383.

Do you have a suggested fix for the development team?

I contacted Paul Talbot and we think this issue is not associated with the numerical precision or tolerance. In the attached word file there is also a cyan highlighted case: At Attempt 3, t=12, the SES has a dispatched value “curr= 18.557” and a lower constraint “V1= 19.317”, and the gap between them is 0.76. Later in Attempt 4, t=12, this constraint is observed.

It is interesting that a gap of 0.76 can be observed but a gap of 0.383 cannot be observed, maybe there is a threshold of such gap in pyomo dispatcher?

Describe how to Reproduce Steps to reproduce the behavior:

  1. Contact me directly and I can add you to my repository access list. I am providing the input file here, but it requires the customized validator and the ARMA to run. heron_input_para_BOP_SES_TES_MW.txt

Screenshots and Input Files Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

alfoa commented 3 years ago

@alfoa

PaulTalbot-INL commented 3 years ago

On further investigation, this is a tolerance issue. The validator in use was imposing a 1e-6 absolute tolerance on a 5e5 value, which was beyond the numerical tolerance of the optimizing solve.

A suggested improvement might be to see if there's a value we can access to tweak the solver's tolerance level, and expose it to the user; or, perhaps, the tolerance for the solver could be propagated to the validator.

PaulTalbot-INL commented 1 year ago

Enough requests came in for this that we've gone ahead with an implementation. We have to do a specific implementation per solver (e.g. glpk, cbc, ipopt, gurobi, cplex, ...) so we've done the three commonly-used open source solvers first. We can add others on request.