Connection flow with representative periods

[aporrasc]

V0.9.2. SpineOpt
v0.15.1 SpineInterface

By using different time blocks on each side of a connection, the flow acquires erroneous behavior.

If I solve my problem without representative periods, everything makes sense. But when I use them the problems appear.

Specifically. I have a storage connected to the electricity node through a connection. The storage has associated the temporal block of a year with a resolution of 1h and the temporal blocks of representative days with a resolution of 1h The electricity node is only associated to the representative days.

It is an investment problem, the optimal solution gives 0 investment in the storage but invests in the connection and the flow does not respect the capacity constraint.

[nnhjy]

Can you give a minimum example DB that replicates the issue?

[aporrasc]

spineopt_example.json

Here is in json fomart.

[aporrasc]

This example lacks annualized costs.

It should be noted that when it comes to a storage - unit - node relationship, the model seems to work well.

[aporrasc]

The problem could be related to this constraint, the connection flow rate. The discharge is double counting the flow rate using 1.94 as efficiency when it should be 0.97. The charge correctly implements an efficiency of 0.97.

The node state balance is zero, but it is optimal if you charge and discharge simultaneously. These expressions represent that if you charge 10 you will be able to discharge 20, it is like a generator behavior. That is the reason the model does not invest in the storage, but it invests in the connection.

In principle, this should come from the fact that I am modeling representative periods and the entire horizon temporal block to obtain seasonality. I think in the backend it is generating an error.

[gnawin]

Had a call with @aporrasc, we found that the errors appear in v0.9.2, but not in v0.8.2. The constraint_fix_ratio_out_in_connection_flow has been changed in this version change. By reverting the constraint to v0.8.2, it works as expected.

So what is the reason for the change, and do we want to revert it? Tagging @Tasqu because we had recent discussion on this constraint.

[nnhjy]

spineopt_example.json

Here is in json fomart.

I tried the given example with the latest master branch, and the model was unfortunately infeasible.
@aporrasc Would you mind further reducing the example model to the smallest possible scope?