Implausible diverging results comparing 1-year-multi-period & multi-period optimization

[mco-sch]

Describe the bug There are implausible diverging results comparing 1-year-multi-period and multi-period optimization.

To Reproduce

• Code (as .txt file) and PV fixed flow data (.xlsx) is attached
• to test 1-year-multi-period optimization, only adjust "end" variable (line 16) to 2025 PV_flow1.xlsx one-year_vs_multi-period_bug.txt

Explanation of (simplified) energy system

• five periods: 2025, 2030,…, 2045
• energy system consisting of...
• ...source resource_el: variable costs = 0.1 (€/kWh) for all periods
• ...potential PV investment: ep_costs (CAPEX) for all periods = 500 (€/kWp), lifetime = 20, interest rate = 0.001, no fix costs etc., defined fixed flow would lead to >1000 kWh/kWp/a
• ...constant electricity sink of 1 MW
• ...electricity_excess

Expected behavior

• investment into PV as of first period, similar to 1-year-multi-period optimization with above-mentioned parameters (Levelized Cost of PV Electricity < resource_el)

Actual multi-period optimization result

• investment into PV only in last period (year 2045)

Additional Context

• I thought about dividing ep_costs by period duration (5 years). This leads to more plausible results for all periods except the last one, as the investments in the last period are too high.

Desktop/System Information

• OS: Windows10
• Python version 3.10
• oemof.solph 0.5.2

---- developers note ---- I adapted the term single-period to 1-year-multi-period as these currently are different implementations but multi-period approach is used for both in this case. By passing data to the periods-parameter multi-period implementation is used which has a different handling e.g. investment costs/annuities, timepoints/timesteps concerning SOC of storages, etc

[mco-sch]

Within the last few days I did some more computations and I am pretty sure about the origin of the problem. It seems, as if investments and flows are not treated equally. Annualized investments are multiplied by the duration of one period (e.g. five years), while flows are not. This leads to the n-fold of investment costs while variable costs are only considered once. Hence, if an investment is competing to a source (e.g. power plant investment vs. electricity import by grid), the investment is unreasonably handicapped leading to wrong results.

It would be necessary to either multiply all flow variables by the duration of one period (the same way as investments are handled) or drop this kind of multiplication for investments.

@jokochems What do you think?

Unfortunately, I am not that experienced within the solph code itself. Maybe someone could leave me a hint about the part of the code to look at so I could go for a try.

[jokochems]

Hello @mco-sch,

sorry for the late and maybe unsatisfactory response:

• I saw this issue a while ago, but just did not find the time to dig into it. (Sorry, I'm kind of finalizing my PhD thesis currently which observes pretty much all the time left besides my day to day work.)
• I think the reason is an "unlucky interplay" between your model configuration / understanding and the current solph implementation status.

Here are some hints regarding your setup:

• Be aware that you compare a multi-period model with 5 periods to one with a single period. So what you referring to as a reference is still a multi-period model.
• Also, be aware that I so far only considered annual periods equaling calendaric years. You are considering 5 year steps which plays a role. But anyways, @nailend and others have this use case, too. I just want to raise awareness that this is something I am not using and which is therefore not thoroughly tested.
• The last thing I want to make you aware of is discounting. I sort of integrated that into the framework and worked with nominal cost values (which admittedly is not so common and complicates things). We are thinking of decoupling that. But you have anticipated it correctly by defining a discount_rate of 0.

Now to the concrete problem:

• A multi-period model only considers the share of an investment that is within the optimization horizon.
• Thus, for the first period, the investment expenses will be converted into annuities that are spread among the full lifetime and for upcoming periods, it is onyl the share of years that spans until the end of the optimization horizon.
• The end year of the optimization horizon in your case is assumed to be 2046. I.e. the model has no information that you assume a five years period - how should it in case we allow for periods of different lengths if you don't explicitly provide it with that information? I'm afraid that is just not yet implemented and might be added to the collection in #1031.
• The annuised investment costs are 25.something. For the last period, the remaining lifetime is only 1. So it is fairly little and seems favourable to invest there. The investments are comparatively high, but this is to the fluctuating nature of your PV source and the idea of installing "too much" to be able to cover the flat demand. In fact, if you simulate the multi-period case with just 1 period, you'll eend up with the same amount of investments.
• Also note that there is no weighting factor for variable costs by default. You would have to explicitly define that. So you are simulating one year for each period which is effectively one year, not one year multiplied by a weighting factor of 5 because of the 5 years long periods.

I hope this helps at least a little and was understandable. You might want to check the calculations within _investment_flow_block.py (line 925 following) to get a better idea of what is happening.

[mco-sch]

Hello @jokochems,

no problem, still thanks for your reply and good luck with your PhD. According to your reply, I assume my initial explanation was not properly enough. Sorry for that. Actually, I am neither concerned about the duration of the last period nor the investment in the last period - this all behaves as expected. But I am surprised that there are no investments before the last period, although this should be the case.

But you are right, applying your use case of annual periods does not lead to this issue. So it only seems to be a problem using multiple year steps. Hope @nailend and others are aware of this bug.

[nailend]

Hello @mco-sch

• Also, be aware that I so far only considered annual periods equaling calendaric years. You are considering 5 year steps which plays a role. But anyways, @nailend and others have this use case, too. I just want to raise awareness that this is something I am not using and which is therefore not thoroughly tested.

Indeed, we have this use case and the current implementation, doesn't fully cover it yet. Especially, your situation is addressed in #992, isn't it? I had this on hold, as we ended up in a more fundamental discussion about having discounting included in the model or not.

• The last thing I want to make you aware of is discounting. I sort of integrated that into the framework and worked with nominal cost values (which admittedly is not so common and complicates things). We are thinking of decoupling that. But you have anticipated it correctly by defining a discount_rate of 0.

To keep maintainability low and have a more generalized approach, we want to exclude the discounting internally but provide functions to directly include all the assumptions in the time series provided to the model. This way it's more sophisticated on the user side to include this, but easier on the side of development and maintainability of oemof.solph.

Please take a look at my implementaion/bugfix for your use case and be free to use it but keep in mind, this might never be merged into the main code-base.

[mco-sch]

Hello @nailend, yes, you are right - my situation is the same as you already addressed. Thanks for this hint. As far as I can see, I solved the issue the same way (weighting variable costs by period duration). Nevertheless, I didn't solve it within solph itself but during pre-processing my data. Up to now, this works fine for me. I will close the issue – thanks for your support.

[nailend]

but during pre-processing my data. Up to now, this works fine for me.

If you are open to it, you can share this preprocessing part on gist and link it here. This way, oemof-users can have a look into it and maybe integrate it later as we are planing to move it to the pre-processing anyways.

Thanks