Combination of roll forwards and investment optimization fails

[hannesfelipe]

Describe the bug
We try to model an investment model in combination with the roll forward parameter. However, the model is not running, unless the roll forward horizon is greater than the investment temporal block.

This is the unclear error message, that does not help to identify the issue. It took us a while to realize that the parameterization of the model was correct (just not the combination of the temporal blocks).

ERROR: LoadError: unable to evaluate expression:
-(0 milliseconds isless {connection_investment_tech_lifetime(analysis_time=Base.RefValue{Dates.DateTime}(Dates.DateTime("2019-01-02T20:00:00")), connection=pipeline_District_Heating, stochastic_scenario=realisation, t=2019-01-02T20:00~(5 hours)~>2019-01-03T01:00) = 10 years} ifelse 1 ifelse 0)
MethodError: no method matching isless(::Dates.Millisecond, ::Dates.Year)

(I skipped the rest of the error message)

To Reproduce
is this even intended as a use case?

In our case, we optimize over the period of one year (also the investment temporal block is one year) with an hourly resolution and a monthly roll forward.

e.g.,

the model start is 2019-01-01T00:00:00 and the model end is 2019-12-31T23:00:00.
roll forward is 730h (its monthly but we divide the hours of the year by 12 to generate the roll forward)
model__temporal_block and model__default_temporal_block have a temporal block with a resolution of 1h
model__default_investment_temporal_block has a temporal block with a resolution of 1Y.

Expected behavior
First, we would expect an error or warning message that clearly indicates the problem.

Second, we would expect that the intended combination is possible and that the model would run infeasible if the investments are not sufficient. This could be the case, if the investments that are based on the information from the first roll forward period are not sufficient to fulfill the constraints in later periods.

Desktop (please complete the following information):

• Which SpineOpt version? 0.8.3
• Which toolbox version? 0.8.2
• OS: Windows

Additional context
We use the roll forward approach to reduce the runtime of the model. We need a hourly resolution but the complexity of our model results in long optimization times for the optimization of the dispatch of one year.

Now, we want to integrate the chance to invest at the beginning of the year into our model. Perhaps, you have another idea how to address this if the combination of the necessary parameters is not working (or let us know how to solve it).

Best regards,
Johannes

[datejada]

@gnawin maybe you can help Johannes

[gnawin]

Hi,
Based on your errors message, the error seems to indicate that SpineOpt is trying to compare two things (::Dates.Millisecond, ::Dates.Year) that are not comparable. Defining years directly as Y introduced problems in the older versions of SpineOpt, because the duration of years was not clearly interpreted (e.g., there can be leap years). You can try to use days instead of years, i.e., 365D instead of 1Y. We have fixed this in the latest version, you could upgrade to avoid this problem as well.

[hannesfelipe]

Hi,
thank you for the help. unfortunately, this is not solving the problem.

We changed to spineopt 0.8.3 before implementing the investments and are up to date.

We also tested it for days but without a successful model creation. We also reduced the optimization horizon to shorter periods (e.g., 48 hours and a roll_forward of 4 hours). However, the error message stays the same and we cannot implement an investment run with rolling horizon.

[DillonJ]

Hi @hannesfelipe I think the issue may be the use of a duration value of years for the connection_investment_lifetime parameter. You could try a value of days instead, or alternatively, remove the parameters and see if that helps as a temporary workaround

[hannesfelipe]

@DillonJ thank you for the idea. I did a short test with a simple model and it seems to work. I let you know if we are also able to run it in our larger model.

[DillonJ]

@manuelma do we need to systematically identify all comparisons between durations in the SpineOpt code and implement more robust methods to capture these cases?

[hannesfelipe]

@DillonJ I would recommend this. We realised another issue in the case of leap years. When simulating one year with a one-year investment period and a monthly roll forward, the model is not investing in any unit, connection or storage in January (just with super high slack penalties and then invests a second time later that year). But, when changing from 1Y to 366D, the model invests from the beginning.

[clizbe]

@hannesfelipe Has your issue been solved? If so I'll close this one.

[hannesfelipe]

With the change all values to days instead of years or month it is working. However, its rather a work around than a fixed issue in the code. Since we are working with changing the input period to days, we never tested other approaches again.

[clizbe]

Thanks! I'll create a couple of issues from this.