Unexpacted flows when using unit_incremental_heat rate or fix_ratio parameters to fix the input to an output flow

[hannesfelipe]

Describe the bug We think that we found an bug when trying to model a idle_heat_rate in combination with a unit_start_flow and unit_incremental_heat rate. Our hast three inflows: steam, raw_methanol and power. The outgoing flow is e_methanol. Steam and raw_methanol are linked with a fix_in_in ratio and raw_methanol and e_methanol with a fix_ratio_in_out_unit_flow ratio.

The power link is used to represent that the unit has some cost (by the cost of the power) when not producing but is on standby. Thus, when producing we use a unit_incremental_heat_rate of 0 (no power needed for the production itself) but a small, positive idle_heat_rate when no production occurs. The unit_start_flow is used to make investments possible (without, the model is not built as there are some specifications missing when using the idle_heat_rate .

To Reproduce

1. Please use the .json files

The file ending with incremental_hr is our simplified approach. Instead of limiting the power inflow on a connection, we left this component out and limited the unit_to_node connection from Power to the unit.

The file ending with fix_ratio is almost the same. However, we removed the before-mentioned parameters and implemented just a fix_ratio_in_out_unit_flow to test if there is a something else not working. Unfortunately, also there is a unexpectedly high consumption of power that is several times higher than the ratio allows for.

Expected behavior We would expect that there is no power consumption at all when having an output flow from the unit. In both cases, thats not the case and non of the parameters seems to set an equal condition between power inflow und e_methanol outflow.

Desktop (please complete the following information):

• Which SpineOpt version? (0.8.3)
• Which toolbox version? (0.14.6.)
• OS: Windows input_data_fix_ratio.json input_data_incremental_hr.json