Costing negative electricity flows - simulating curtailment

[arao53]

• Assigning a negative value to the costing.electricity_cost parameter could be useful for simulating grid curtailment conditions.
• Currently, flowsheets using the WaterTAP costing package fail to solve when encountering costing.electricity_cost<0

2022-08-12 14:53:45 [WARNING] idaes.core.base.costing_base: flow_expr is an expression with a lower bound of less than zero. Costing requires that all flows have a lower bound equal to or greater than zero to avoid negative costs.

[andrewlee94]

@arao53 Are you seeing an actual error/failure in the model due to this? Note that that message is just a warning, and by itself does not indicate a failure.

[arao53]

@andrewlee94 the full error is copied below. When running the RO_with_energy_recovery.py using the parameter sweep tool, all outputs return nan for negative electricity cost.

` "../watertap/examples/flowsheets/RO_with_energy_recovery/RO_with_energy_recovery.py", line 547, in m = main(variable_efficiency=VariableEfficiency.flow)

File "../watertap/examples/flowsheets/RO_with_energy_recovery/RO_with_energy_recovery.py", line 61, in main solve(m, solver=solver)

File "../watertap/examples/flowsheets/RO_with_energy_recovery/RO_with_energy_recovery.py", line 337, in solve assert_optimal_termination(results)

File "..\lib\site-packages\pyomo\opt\results\solver.py", line 165, in assert_optimal_termination raise RuntimeError(msg)

RuntimeError: Solver failed to return an optimal solution. Solver status: warning, Termination condition: infeasible `

[andrewlee94]

So, that in itself is a solver error due to an infeasibility. From what you have said, it looks like this is due to either a bound or a constraint on the electricity cost, however I am pretty certain that costing.electricity_cost<0 does not appear in the model in that form.

So, the next question is whether that is due to a bound on cost or an inequality constraint (and I suspect the former).

[arao53]

In idaes/core/base/costing_base.py it looks like the cost_flow method looks for the lower bound of the flow expression, but I'm not exactly sure where this bound set.

I am not aware of any inequality constraints that are created for costing at the flowsheet level. Could this bound/constraint be created from one of the methods from the WaterTAP costing package?

[andrewlee94]

@arao53 I though that was the case, and that basically explains (one of) your problems.

You are seeing a warning (the one in your original issue) because the electricity cost is unbounded - the costing framework is checking, seeing that there is no bound and warning of this fact. It is not setting any bounds for you. This means that (unless you are setting bounds later), this cost is unbounded and if you try to minimize it it might go into a negative cost and keep on going.

That is the reason for the warning you are seeing - to let the user know the problem is possibly unbounded and that they need to address this before continuing. For simplicity, we say that it should be bounded to 0, but you should be able to relax that (subject to having a good value).

However, the fact that the solver is reporting an infeasible solution suggests that there is probably another issue somewhere. An unbounded problem will generally not come back infeasible - it will either be reported as unbounded or run into some other sort of issue first. So, I suspect you need to look elsewhere to find the real problem here.

[ksbeattie]

@arao53 is this still an issue or can it be closed?

[wigging]

I'm getting the same warning for the zero-order electrocoagulation model. See comment in pull request #953. Bounds are set on everything in the model so I don't why the warning occurs.

[WARNING] idaes.core.base.costing_base: flow_expr is an expression with a lower bound of less than zero. Costing requires that all flows have a lower bound equal to or greater than zero to avoid negative costs.