Multi-period investment optmization: no investment in first period about oemof-solph HOT 6 OPEN

Ouch, that's quite bad, I have to admit. Thanks for pointing this out, @SabineHaas!

I haven't come across this issue, yet, as I have been working with brownfield scenarios, mostly.

I am pretty sure that it relates to the multi-period storage implementation and the definition of the 0th storage state, to be more precise, this code section.

My idea here was to force storage levels to equal 0 until an investment happens. But what the rule effectively does is to prevent storage investments for the 0th (i.e. the very first TIMESTEP).

I commented out the lines mentioned above and the optimization yielded results as you'd have expected them, i.e. no shortage is activated and investment results for both cases are identical.

I haven't given it enough thought yet, but my gut feeling is that the respective rule might be safely removed.

@nailend: Would you second that opinion of mine?

from oemof-solph.

I tried to wrap my head around, but I didn't really understand why this constraint doesn't work. But this is a direct consequence of #1030 isn't it? In multi-period, the distinction between TIMESTEPS and TIMEPOINTS don't exist?

from oemof-solph.

I tried to wrap my head around, but I didn't really understand why this constraint doesn't work. But this is a direct consequence of #1030 isn't it? In multi-period, the distinction between TIMESTEPS and TIMEPOINTS don't exist?

Yes, you are right. The two issues are interrelated and there only is the TIMESTEPS set for multi-period models.

• What I wanted to do - as I describe above - is to ensure new-built storages are initially empty. Now there is the follow-up issue with defining the initial storage level.
• In the previous version of solph (i.e. before the TIMESTEPS / TIMEPOINTS split), there was an initial storage level defined before any flow happening (so at time -1 if you want to think about it that way). After that, the storage content variables and the flows had the same time indices (from the TIMESTEPS set), wereby the storage content variables were a result of the (in- and out)flows happening into the storage.
• In the current version of solph, it was decided to make this behaviour explicit by introducing the TIMEPOINTS set with one entry more to properly index storage levels.
• I wanted to recreate the behaviour of the old solph version (because I found it easier to implement and started with that while the TIMESTEPS / TIMEPOINTS split happened in the meantime). I think the error I made here is that I fixed the 0th instead of the -1st time step with the constraint I referenced.

As I see it, there would be three options:

1. Simply remove the constraint. This would allow to freely choose a storage level. You'd have to think about whether this might create the model artefact of filling a storage for free, though ...
2. Adjust the constraint to recreate the behabiour of the previous solph version.
3. Align with the current version of solph.

I think option 3 is clearly preferrable. In that course, also the investment storage implementation in general should be revised, see #1030.

from oemof-solph.

Simply remove the constraint. This would allow to freely choose a storage level. You'd have to think about whether this might create the model artefact of filling a storage for free, though ...

In fact, the assumption that a newly installed storage is always empty is not valid in all cases. Think of rechargeable batteries: If receive them at 0 % capacity, they are probably broken.

from oemof-solph.

Thanks, @p-snft. You are totally right about this. I also thought about pumped storage which will probably come with some filling level initially.

@nailend and @SabineHaas: Look what I found: #965
The constraint was not always there. I added it as sort of a hotfix after I have been informed by a user facing trouble with storages that were initially filled "for free".

@nailend I also had some trouble with proper storage roundtrip conditions (there actually are none yet), but that was before your sophisticated lifetime tracking thing. It might be worth a shot tackling this as well - maybe in a dedicated issue/PR.

from oemof-solph.

Thanks, @p-snft. You are totally right about this. I also thought about pumped storage which will probably come with some filling level initially.

Not sure, what's the better solution to be honest, but I prefer to set the initial content per component.

Look what I found: #965

well I confirmed, haha

@nailend I also had some trouble with proper storage roundtrip conditions (there actually are none yet), but that was before your sophisticated lifetime tracking thing. It might be worth a shot tackling this as well - maybe in a dedicated issue/PR.

you mean roundtrips within a period?

At the dev-meeting, we shared the common interest to somehow replace single-period with multi-period. For this to happen, there are a few things to be done before. I will open an issue, where we can collect the necessary changes/improvements.

from oemof-solph.