Feature/usability: Allow input of precalculated time series and different SAM SI modules

[Piranias]

Fix #313, #300, #285, #312, #165, #125

Changes proposed in this pull request:

• add new input parameters to main.apply_pvcompare()
• new function "add_pv_timeseries()" to pv_feedin.py

The following steps were realized, as well (required):

• Update the CHANGELOG.md
• Check if full simulation tests pass locally (EXECUTE_TESTS_ON=master pytest)

Also the following steps were realized (if applies):

• Use in-line comments to explain your code
• Write docstrings to your code
• For new functionalities: Explain in readthedocs
• Write test(s) for your new patch of code

Please mark above checkboxes as following:

• Open
• Done

In case of an error due to linting, run black . --exclude docs/ and push your changes.
Note that in case you do not fix a whole issue you should start your PR with Address #xyz.

_{For more information on how to contribute check the CONTRIBUTING.md.}

[Piranias]

@SabineHaas , I will still add more informations about the features in the rtd. If you want you can start your review on the functionality and give me a feedback already

[SabineHaas]

Nice that you make this possible :)

Concerning weather data and pv time series I agree that it makes sense to introduce a parameter.
For demand I think it would be more convenient to check whether the file named in energyConsumption.csv already exists (no calcluation) or not (demand time series is calculated and saved + file name saved to energyConsumption.csv).

This is how it is done for COPs of heat pumps already around here

[Piranias]

Nice that you make this possible :)

Concerning weather data and pv time series I agree that it makes sense to introduce a parameter.
For demand I think it would be more convenient to check whether the file named in energyConsumption.csv already exists (no calcluation) or not (demand time series is calculated and saved + file name saved to energyConsumption.csv).

This is how it is done for COPs of heat pumps already around here

Hmm, I'm not sure if I like this solution. Because e.g. when running two simulations after each other for two loactions, the file in energyConsumption.csv does exist, but it's not the right one. This way the user would always need to open and edit the file or delete the old time series. There could be another check for the location AND whether it exists, but then the user would need to provide a specific filename scheme for their file AND put the file into the right folder before.

This way it's decoupled, you can specify any path and filename.

[SabineHaas]

okay, I am fine with this - and I agree that it is more flexible.
Could you adapt the process for COPs as well then? I think it should be consistent.

[Piranias]

okay, I am fine with this - and I agree that it is more flexible.
Could you adapt the process for COPs as well then? I think it should be consistent.

I have come across the mechanism with the COPs before and I know that it's very interlaced. Therefore I'd prefer @MaGering to do this in another PR. I don't want to mess up your structure :) see #321

[SabineHaas]

It's important that we first merge #309, otherwise @Stefanie08 could get nasty merge conflicts which might be difficult for her to solve.

• I've found some strange dots here: https://pvcompare.readthedocs.io/en/latest/model_assumptions.html#id18 maybe you can fix this as well?
• It would be nice if you add assertion statements to your tests
• You could also test the cases that one wants to provide own time series but the file does not exist (and is then calculated by pvcompare) or provides a wrongly formatted dict for PV

[SabineHaas]

It's important that we first merge #309, otherwise @Stefanie08 could get nasty merge conflicts which might be difficult for her to solve.

@Piranias I have thought about the merge again: I would do it after the release. The reason for this is that I would reference pvcompare with the release tag in our working paper. Of course, the changes in this PR should not change any results, but I still prefer to state the version of pvcompare that we have used for the simulations.

I have fixed the bug for which we could not do the release - maybe we can even finish it this week. If not, you can still finalize this PR and I can merge it after the release is done.

[Piranias]

It's important that we first merge #309, otherwise @Stefanie08 could get nasty merge conflicts which might be difficult for her to solve.

* I've found some strange dots here: https://pvcompare.readthedocs.io/en/latest/model_assumptions.html#id18 maybe you can fix this as well?

* It would be nice if you add assertion statements to your tests

* You could also test the cases that one wants to provide own time series but the file does not exist (and is then calculated by pvcompare) or provides a wrongly formatted dict for PV

i added the tests and updated all other changes. Except of the assertion statements, which i found less important right now, since we dont have any for the other tests as well..