Sabine Haas

Hmm no I think it's fine like that. Maybe you could quickly comment on, whether this is intended like this @smartie2076 : - `source_non_dispatchable_optimize()`: use `TIMESERIES_NORMALIZED` as this is needed...

Are we still going I lost overview over the input data checks. @smartie2076 is this already tackled and if where could you add the link please?

> You`re right, this is not very intuitive and there is also an error message popping up when the user does it wrong. So we should document this better. @SabineHaas...

> I think I merged the PR but I don't see a single commit I signed in it. I only added a warning message if the maximum cap was smaller...

Another point @smartie2076 mentioned is that `installedCap` might have to be adapted, as well. I tried to find out via the lp file what is happening with installedCap, but I...

Today with @smartie2076 we discussed parts of this issue including hotfixes and longterm fixes. I'll summarize here and add new issues. - A fast fix for this issue will be:...

maximum installed capacity constraint (`maximumCap`) was added for - dispatchable and non dispatchable source (energyProduction) in #237 - transformers in #243 - storages in #243.

The link to the comment doesn't work - at least for me..

This is solved for pvcompare, as we are going to calculate KPIs in post-processing - we need a fast solution now. I don't close this issue as you might discuss...

In our discussion we weren't sure whether the optimal capacity will be determined based on inputs or outputs. Thanks @smartie2076 that answers my question and is the behaviour I expected.