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

[tarskul]

Deleted two spam comments.

[danajhen]

I have just tried running the database and further uncovered the bug: the fix_ratio_in_out is ignored completely. The only way that I found it to be working was to create not an in out relation but an equivalent in_in relation between Power and one of the other inputs (steam and raw_methanol).

This is the input data with the alternative approach:
input_data_fix_ratio_in_in.json

There is no problem with the incremental heat rate as far as I can tell.

[tarskul]

For the file with the incremental heat rate I do indeed get a very large value for the power. But for fix_ratio.json I get the expected value of 20 both for 'Power_Kasso' and 'e_methanol' and 25 for 'raw_methanol' which corresponds to the fix_ratio equal to 1 for Power_Kasso and e_methanol and the fix_ratio of 1.25 for e_methanol and raw_methanol.

But it is true that our tests do not cover all possible combinations. Now we may have a reason to improve upon this.

There are also a lot of changes at the moment with the incremental heat rate. Very recently the functionality has been removed and replaced by a more general piecewise-linear formulation. I think I also saw some changes in the fix_ratio passing by.

I guess we'll have to get a birdseye view of what is going on. We'll discuss this in an upcoming developer meeting.

[hannesfelipe]

@tarskul thank you for checking it. One follow up question: Do you have an idea why the fix_ratio.json is running as supposed in your case but not in our case?

As mentioned above, SpineOpt and SpineToolbox should be up to date.

[DillonJ]

@tarskul do I understand correctly that you do not get the behaviour described? I.e. it is working for you?

We did have issues recently when a single flow was involved in multiple fix_ratio parameters. That was fixed (for all I know) in a recent commit - but it is possible that this is another use case that we haven't tested as @tarskul mentions.

For now I would like confirmation that someone has verified an issue with latest master?

@hannesfelipe the issue was fixed in a very recent commit - can you please confirm you are on latest master?

[DillonJ]

@nhniina This is a nice use case for multiple inputs and and single output. Is it as nicely handled in the new data structure?

[tarskul]

I did a fresh install last friday (30/08/2024).

[DillonJ]

@hannesfelipe just to mention as @tarskul has mentioned that in a very recent PR, idle_heat_rate and incremental_heat_rate have been deprecated. In your call to run_spineopt() you will need to specify the keyword argument upgrade=true to run the migration scripts where all incremental_heat_rate parameters will be converted to fix_ratio_out_in_unit_flow and all idle_heat_rate parameters will be converted to fix_units_on_coefficient_out_in

[hannesfelipe]

@DillonJ thank you for the hint to use the upgrade argument to run the migration scripts.
I have a question regarding the fix_units_on_coefficient_out_in: Is this flow positive in all cases the unit is on? I am asking because the idle_heat_rate was a positive flow in cases the unit was on, but there was no outgoing flow (stand-by case of a unit).

Second, this does not fix the issue of unlimited flows. They still appear.

[nhniina]

I tested with the input_data_incremental_hr.json and the latest master.

There seems to be an issue in SpineOpt that the units_started_up and units_shut_down variables are not limited to the total number of units (incl. investments). The model is now starting up and shutting down a lot of units at the same time because of unit_start_flow (that equals to 1) and negative vom_cost of the electricity node.

Because in your case, unit_start_flow was a parameter just required to make the old heat rate equation work, I think you can now remove it from your input database, as you have done in the other file. By setting that to zero / removing it, I get the model behaviour I expect: the unit is consuming a fixed amount of electricity whenever it is on, regardless of the e-methanol output.

I think that should have been the behaviour with the old idle_heat_rate as well.

In fact, your use case seems to be quite complicated. Did I understand it correctly that

1. If the unit is offline, it consumes no electricity and produces no e-methanol
2. If the unit is online and produces e-methanol, it consumes no electricity
3. If the unit is online and produces no e-methanol, it consumes a fixed amount of electricity?

In addition, there is no cost for start-ups/shutdowns or being online and no minimum up or down times?

EDIT: Removing my old comment about fixing the simultaneous start-ups and shutdowns. There is already a suggestion to model minimum up and down time of 1 unit of time (e.g., 1 hour) to avoid simultaneous start-ups and shutdowns: #960 (comment)

[hannesfelipe]

@nhniina it seems we have to re-install SpineOpt then. Even when removing the unit_start_flow parameter and using fix_ratio_out_in_unit_flow and fix_units_on_coefficient_out_in, I still get the problem in the investment case. Did I get it correctly, that in the investment case, the model seems to ignore the maximal number of units in some cases?

Regarding your question: Indeed that's our approach. I know it seems weird but we wanted to avoid the unit_on_costs. In our way we can link it directly to the electricity price as we already have it in the system. With the unit_on_costs, we would have to add the same time-series as unit_on_costs to all units separately.

[DillonJ]

Hi @hannesfelipe. I am trying to understand the specific functionality of SpineOpt that is not working as you expect.
unit_idle_heat_rate (or (fix_units_on_coefficient_in_out) creates a constant term in the fix_ratio constraint when the unit is online, so when online, there will be a constant input flow independent of the output flow.

Using fix_ratio_in_out_unit_flow and fix_units_on_coefficient_in_out create the following constraint:

flow_in = units_on x fix_units_on_coefficient_in_out + flow_out x fix_ratio_in_out_unit_flow

A unit has only a single units_on variable per timeslice, that will be common to all fix_ratio_ and heat_rate constraints and flows. However, a unit can have any number of input and output flows as created by unit__from_node and unit_to_node relationships respectively.

Unless I have misunderstood, it seems like you are expecting different behaviour.

If you somehow need a second, independent units_on variable, you can create another unit. A nice trick is if you create a unit with no flows (no unit__from_node or unit__to_node relationships) then it only has a units_on variable. You could use this in some user_constraints to achieve the behaviour you are looking for.

Hope that helps

[clizbe]

@hannesfelipe Do you have an update on this?

[hannesfelipe]

@clizbe I am sorry that I forget to answer.

We found a solution to model the problem (it's not perfect but it works). However, we still have the issue of the model being unbound in the case of the fix_ratio example.