Hello @jokochems! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2023-12-08 16:40:39 UTC

This is a draft with yet untested functionality, just to get a first impression. I need to add tests as well as to touch the GenericInvestmentStorageBlock as well as the SinkDSM investment blocks.

Though the future of this feature is subject to debate, I came across an issue which might be of interest:

• I'm solving a really large model instance and have deactivated the crossover algorithm of the solver due to complexity and runtime reasons and use barrier algorithm for solving (which provides a super-close to optimum solution, but with slight numerical unprecision).
• Thus, one solution for my particular problem would be to round investment variables before a repeated solve. I think, I'll add that as an optional feature add-on (since I kind of require it super short notice).
• We can still discuss on how to proceed, @p-snft. I see your points concerning the maintability and structure issues (also reaching beyond this PR) - I just don't have the capacities at the moment to provide a more general approach.

I do see your personal need for this adjustment. However, I fear that this is introducing code dept for a very limited use case. There are several use cases that require a very similar functionality but would not be possible with this one:

• Optimise investment as well as operation including demand rate for electricity. Then fixing the investments but leaving the peak demand as a variable. This would not work as optimising the peak load is not distinguished from investments.
• Optimise day ahead energy trading based on a forecast. Then switch to slightly different energy demands and optimise intra-day trading.
• Run a multi-period investment model, then fix the sizes just of the technologies that have a long planning phase (but not e.g. small scale PV installations) to emulate multiple medium-term scenarios that an still work out once an initial decision is taken.

Unfortunately, I am also lacking the time to implement this in a more generic way. Thus, I propose to leave this open as a reference or until someone find the time to do it.

Hi, thanks for the response. I totally understand it and find it a good suggestion to simply leave it open. (Btw: I'm still facing some numerical issues which lead the model to be solved again to be infeasible. But maybe I just have to choose an even higher rounding precision for my particular use case.)

You did not request any particular code changes, did you? This was more on the general need for a revision and it to be more generic.

What would be a cool thing would be to provide a list of variables you want to fix for another run / units you want to exclude from fixing. That might also be dispatch-related ones and allow you to exclude dedicated investment variables as for the example you provided above.

Yes, I did not come up with specific requests.

What would be a cool thing would be to provide a list of variables you want to fix for another run / units you want to exclude from fixing. That might also be dispatch-related ones and allow you to exclude dedicated investment variables as for the example you provided above.

If this was implemented, the approach should be general enough to be merged, I guess.