[Release] Minimal requirements for first release for partners

[smartie2076]

For the first release that is promoted to the partners, we do not have to fullfill all requirements outlined in #532. Instead, we should aim to finish the most pressing requirements and include the most important features. Below, I will gather the checklists of the different categories:

General

• [x] Move from mvs-eland to multi-vector-simulator
• [x] (1.) Installation option via pypi (#588) @Bachibouzouk @SabineHaas
• [ ] (last) Official release version on master @smartie2076 @Bachibouzouk

Features

• [x] Simulate sector-coupled energy systems
• [x] Cost-postprocessing: NPV, LCOE
• [x] (4.) Renewable share decision: Individual sectors or also applying weighting? (#636) @smartie2076 @Bachibouzouk
• [x] (5a.) Definition of energy busses via csv (#635) -> (#649)
• [x] (5b.) Excess generation (#559) @SabineHaas
• [x] Minimal renewable share constraint
• [x] Maximum capacity constraint
• :x: Ability to interconnect the capacities of bi-directional assets (#24, #133) -> add-on feature
• :x: (11.) Optional: Degree of sector-coupling (#702)
• [x] (12.) Degree of autonomy (energy balance) @Bachibouzouk -> I think @Piranias uses this in #603
• [x] (13.) Percentage of self-supply (hourly, #603 ) @Piranias
• [x] (14.) Percentage of self-consumption (hourly, #603 ) @Piranias
• [x] [optional] CO2 emissions (#677)

Testing

• [x] Basic component benchmark tests
• [x] Benchmark test for minimal renewable share
• [x] (6.) Benchmark test for cost-postprocessing (LCOE for single and sector-coupled systems) #613 @smartie2076 @Bachibouzouk

Readthedocs

• [x] (15.) Upto date installation instructions (#601) @SabineHaas @Bachibouzouk
• [x] (10.) Model assumptions: CHP, thermal storages, geothermal conversion assets (#779) @SabineHaas
• [x] (9.) Model equations (#581) @ursulaelmir @smartie2076
• [~] (7.) Parameter descriptions (#586) @Bachibouzouk @smartie2076
• [x] (8.) Limitations (#580) @ursulaelmir @smartie2076

Bugfixes

• [x] (2.) Mislabeled efficiency for storage (#295) @SabineHaas
• [x] (16.) Representation of battery discharge in plots (#444) @SabineHaas
• [x] (3.) Transformers: Definition of input- and outputs (#389, #246) @SabineHaas
• :x: [look at] Possible loops between feed-sink and consumption-source (#119) -> during simulations
• [x] Report is incorrectly formatted (#535, #634) @Bachibouzouk
• [x] Path issue for generating the report (#594) @Bachibouzouk
• [x] Label might be an unneeded parameter in the csvs (#375) @SabineHaas
• [x] Fix math equations in RTD (#604)
• [x] Enter feed-in tariff as positive value (not, as right now, as a negative value) (#610) @SabineHaas
• [x] Fixcost.csv not used as a file or functionality #655 (@smartie2076)

[smartie2076]

TBD: Which other points should be added to the minimal requirements, compare #532

• [ ] Bi-directional inverters
• [ ] More KPI

[SabineHaas]

We didn't add #451 to the list above, but I think we said, that I should do that for the release, as well.

[smartie2076]

We didn't add #451 to the list above, but I think we said, that I should do that for the release, as well.

I think it is somewhat optional.

I was also wondering if I should address this:

When using two conversion objects to emulate a bidirectional conversion assets, their capacity should be interdependent. This is currently not the case (#24, #133 )

Otherwise, one has to follow some kind of weird practice to define a bi-direcitonal inverter, and the input/otput capacities would be different. Also, one would have to distribute the costs between both assets, which also does not make any sense from the optimization point of view. It is again something that is very difficult to explain to the end-user, when the results change because of a later fix.

[SabineHaas]

I would include it

[smartie2076]

How about the fix costs that we are currently not using? Do we want to include that in our minimal release? Its about the project costs that are not changed by the investment. If we are not using it, we should remove the field before our first release, I would say.

[Bachibouzouk]

How about the fix costs that we are currently not using? Do we want to include that in our minimal release? Its about the project costs that are not changed by the investment. If we are not using it, we should remove the field before our first release, I would say.

I don't think we are using them, I agree to get rid of them (we need to do so also from RTD)

[smartie2076]

I think I do not understand @Bachibouzouk and @SabineHaas - do you want to delete the fix costs because we do not use them or because you think that we do not need to use them?

[SabineHaas]

I think I do not understand @Bachibouzouk and @SabineHaas - do you want to delete the fix costs because we do not use them or because you think that we do not need to use them?

I would delete them because we do not use them. But maybe I haven't understood the purpose of using them, yet. Do you still see any purpose for using them @smartie2076 ?

[smartie2076]

I think I do not understand @Bachibouzouk and @SabineHaas - do you want to delete the fix costs because we do not use them or because you think that we do not need to use them?

I would delete them because we do not use them. But maybe I haven't understood the purpose of using them, yet. Do you still see any purpose for using them @smartie2076 ?

Well, if an end user knows that for initiating this or that project different fix costs occur (may be internal costs), then comparing two scenarios with different fix costs becomes tedious if you can not define them in the MVS itself. You can not compare the LCOEs anymore, nor the annuities. Therefore my idea was to allow end-users to define the fix costs somewhere, eventhough they are not used for the simulation itself but for a manual scenario comparison later.

[smartie2076]

I still like the feature, but think we could simplify: Not an own file for fixcosts.csv, but maybe wrapped in project_data. We then would also have to add this in the cost post-processing in E before the minimal release.

[SabineHaas]

If I look at it from a user perspective I would keep the two files separately. e.g. in pvcompare we use project_data.csv (location, country, scenario_id,...) but not fix_costs.csv (as far as I can say from my knowledge about the purpose fix_costs).

[smartie2076]

@SabineHaas can you cross off number 10 of the checklist when you fix #779? @Bachibouzouk I know you will not manage to fix number 7 (parameters) until the beta release, but thats fine. Can you change the checkmark to :x: if this is not included in the beta release?

@ciaradunks @Bachibouzouk this issue can be closed when you do the beta release tomorrow! (The beta release is not MVS 1.0.0, but should be MVS 0.X.X).