Temporal structure for investment and operation blocks

[gnawin]

For the multi-year investment feature, we would like to run a single optimization with milestone years both for investment and operation, e.g., investment (once a year) in 2030 and 2035, and operation (hourly within a year) also only in 2030 and 2035. This concerns using different temporal blocks for investment and operation, which are nonconsecutive. We did some tests to see if SpineOpt can do this. The results suggested that SpineOpt can almost do things correctly, but still not completely.

Here are the test cases:

Case 1 (only operation)

Everything works fine.

Case 2 (operation + investment)

The operational blocks are nonconsecutive, and the investment block is consecutive. The model does not break, but the results are not correct. Depending on the resolutions of the investment and temporal blocks, the balance constraints are (partially) not generated.

Case 3 (operation + investment)

Both the operational blocks and the investment block are nonconsecutive, if they are the same resolution, say both daily, then everything works fine.

Case 4 (operation + investment)

Both the operational blocks and the investment block are nonconsecutive, if they are not the same resolution, say daily for investment, hourly for operation, then units_available_transition constraints are not correctly generated. In our test of 2 investment blocks, this constraint is not generated for the second block, and so the investment results are wrong.

Idea

If either case 2 or case 4 works, the multi-year feature would be almost there. Unfortunately, according to our tests, they do not yet work. I guess that SpineOpt currently does not distinguish t_before and t_after for investment and operational blocks, but only generates them for all the blocks. I think that these cases can work if the temporal structure could be modified slightly to reflect this modeling purpose.

@manuelma @Tasqu @datejada

[gnawin]

After discussion with @Tasqu @datejada , we suspect that indeed, when SpineOpt generates time slices for constraints, it considers all the temporal blocks (even including temporal blocks that are not explicitly used in the model). This makes it difficult to model milestone years, as we wish (i.e., to model investments with consecutive temporal blocks and operations in non-consecutive temporal blocks with different resolutions, respectively), at least in theory. Because some constraints depend on consecutive temporal blocks as they need t_before for the second block, which includes, e.g., balance constraints and unit invested transition constraints.

Case 2 and Case 4 show this issue. In Case 2, for the beginning of the second block, balance constraints look for t_before but wrongly find the investment temporal block, and thus they are not generated. In Case 4, transition constraints try to find t_before but wrongly find the operational temporal block, and thus they are not generated.

The solution is either to remedy the temporal structure or to find alternative ways to achieve the goal.

Proposal 1: remedy the temporal structure

The problem arises when operational temporal blocks and investment temporal blocks are mixed up while they are not desired to be. We can make sure that this is not the case anymore. One idea is to have three temporal structures, the current one, one for operational temporal blocks, and the other for investment temporal blocks. A switch can be added to only generate those when use multi-year investments.

Pro: it fundamentally resolves the problem
Con: implementation is more time-consuming (it might need expert knowledge of the temporal definitions in SpineOpt)

Note: For each constraint, we need to define whether it is in the operational or investment temporal blocks. For constraints that link operational and investment variables, we must define which one to use (probably the operational one, e.g., unit capacity constraint).

Proposal 2: find alternatives

Proposal 2.1: add an extra time slice before each operational block

To deal with the problem that the operational constraints are not correctly generated for the beginning of the second block, we can add an extra time slice before each operational block, just to make sure that it exists so that the constraint for the first time slice of the second block can be generated.

Pro: easy to do
Con: this extra time slice may introduce some unintended behaviour (what can go wrong, such as costs?); it removes the connection with the previous state, such as storage (the user can define an initial state for the second temporal block. For now, we should not cover the case of linking the storage state of non-consecutive operational temporal blocks)

Actions for this proposal:

• Test the implications of the extra time slice in all the constraints for the transition from this time slice to the first one in the second temporal block, especially the constraints that have temporal parameters (i.e., delay connection, storage level, minimum up/down time, ramping). We need to check that the constraint is correctly written and see if the user needs to define an initial constraint for these parameters or if the defaults work fine.

  Update 2024-07-05:

  • storage level (node_state) works fine. You can define a fix_node_state for the beginning of each period, and have to set it to 0 for the extra time slice.
  • unit commitment: for the extra time slice, you need to set "fix_unit_on" to 0, then the behavior will be the same as the first block
  • there are a few other variables you can fix by using "fix*", like "fix_unit_flow". In principle, you can fix all those, but maybe it is not needed.

• Changes in the economic representation to account for this use case (milestone years for operational time block)

Proposal 2.2: manually close the gaps

For the case of investments and operation in 2030 and 2035, there is a gap in between that causes issues. We can put the data in 2030 and 2031 to close the gap, and when post-processing change the years back to 2030 and 2035.

Pro: easy to do
Con: since the investment years are changed to SpineOpt, the internally calculated economic parameters would not work anymore; overhead in post-processing; we link the state of the two periods (what is desired?);

Proposal 2.3 simultaneously run two blocks as stochastic scenarios

Consider the milestones as two stochastic scenarios, one for one operation year and the other for the other, so the investments will cover these two years.

Pro: milestones can be run in parallel?
Con: the internally calculated economic parameters would not work anymore; it is not fully clear whether this will work and if so, how to set it up.

[tarskul]

I'd say let's go for proposal 1 but let's take the time to think it through. Adding 2 temporal structures and (especially) switches may be confusing for (new) users. Maybe we should give all the switches a similar name such that it becomes clearer (e.g. toggle_this, toggle_that) but that is perhaps a separate issue.

Instead, we may want to think about a way to apply temporal and stochastic structures to subsets in general. At the moment we can assign the structures to "all" and specific units, nodes, ... (as well as groups of these?). Now we want to extend that to more abstract sets like operation and investment. Maybe in the future there will be other parts of the formulation that we want to cover as well? Maybe we want to allow users to define their own sets?

That remains us with two questions. The first question is whether we can avoid hardcoding these abstract sets. Do we need to make them specific for each case (e.g. operation and investment) or can we make sets for any group of equations (even if it does not always make sense)?

The other question is on the data side. How can we "connect" the temporal and stochastic structure to an abstract set? It is most likely a switch but the way we implement it, can feel different for the user. Is that abstract set a separate entity like "scenario" for the stochastic structure? Is it a dropdown list inside the temporal and stochastic structure? Is it a property of the relation between the temporal structure and the model block?

[datejada]

At TNO, we suggest the following:

• short-term actions: Proposal 2.1
• long-term actions: Proposal 1

[datejada]

@gnawin After discussion, we will start implementing proposal 2.1 and afterwards see improvements according to the other proposals