greco-project/pvcompare

pvcompare is a model for comparing the benefits of different PV technologies in local energy systems in different energy supply scenarios.

Deprecated:

pvcompare

Introduction

pvcompare is a model that compares the benefits of different PV technologies in a specified energy system by running an energy system optimization. This model concentrates on the integration of PV technologies into local energy systems but could easily be enhanced to analyse other conversion technologies.

The functionalities include

• calculation of an area potential for PV on rooftops and façades based on building parameters,

• calculation of heat and electricity demand time series for a specific amount of people living in these buildings,

• calculation of PV feed-in time series for a set of PV installations on rooftops and façades incl. different technologies,

  • all technologies in the database of pvlib,
  • a specific concentrator-PV module (CPV) and
  • a module of perovskite-silicon cells (PeroSI),

• calculation of temperature dependent COPs or respectively EERs for heat pumps and chillers,

• download and formatting of ERA5 weather data (global reanalysis data set),

• preparation of data and input files for the energy system optimization,

• a sensitivity analysis for input parameters and

• visualisations for the comparison of different technologies.

The model is being developed within the scope of the H2020 project GRECO. The energy system optimization is based on the oemof-solph python package, which pvcompare calls via the Multi-Vector Simulator (MVS), a tool for assessing and optimizing Local Energy Systems (LES).

Documentation

The full documentation can be found at readthedocs.

Installation

To install pvcompare follow these steps:

• Clone pvcompare and navigate to the directory \pvcompare containing the setup.py:

git clone [email protected]:greco-project/pvcompare.git
cd pvcompare

• Install the package:

pip install -e .

• For the optimization you need to install a solver. You can download the open source cbc-solver from https://ampl.com/dl/open/cbc/ . Please follow the installation steps in the oemof installation instructions. You also find information about other solvers there.

Examples and basic usage

The basic usage of pvcompare is explained in the documentation in section Basic usage of pvcompare. Examples are provided on github in the directory examples/.

Contributing

We are warmly welcoming all who want to contribute to pvcompare. Please read our Contributing Guidelines. You can also get in contact by writing an issue on github.

pvcompare's Issues

Adapt tests: only use data in tests directory

For example here for the pv_setup the constants.DEFAULT_INPUT_DIRECTORY is used, which causes some tests to fail when the pv_setup.csv is changed.

You can use teardown_method() f.e. for deleting files after each test, teardown_class() for doing operations after test class is was run through. examples in test_heat_pump_and_chiller.py.

Also very useful are fixtures, see f.e. here in test_heat_pump_and_chiller.py.
The basics are this:

@pytest.fixture(scope="function")  #  f.e. scope="class" for whole class
    def your_fixture(self):
        ... do operations here ...
        yield return_something_here  # provide the fixture value
        ... do operations after the test function was carried out here ...  
        # also useful for resetting files / deleting files

remove water heating from heat_demand

As discussed in our last meeting the water heating should be removed. Is this a final decision or should it just be commented out for now?

calculation of yearly time series reasonable?

After our discussion on the project duration I asked myself whether it makes sense to calculate year-specific timeseries in pvcompare if the project duration is greater then one year anyways. It is kind of time consuming to always calculate the timeseries anew. Of course the option should be available, but maybe it would make sence to have "default" timeseries for a 'random' year for each location that can be used if the project duration >> 1 year. So my question is: would we then just calculate a timeseries of any year, or should we reather add a TMY year (this is not available in era5 and would need to be implemented)?

any ideas on that?

Time series need unit

To prevent confusion I suggest to change the column name of the mvs input time series in this folder to the unit of the time series. This is already done for the pv time series and needs to be changed for the demand profiles.

[Bug] dev build fails for python 3.6

see
https://travis-ci.com/github/greco-project/pvcompare/builds/186235983

Checklist to make sure that the bug report ist complete:

• OS: your_operating_system, your_distribution
• Branch: branch_name, updated on update_date_and_time
• If applicable: Attach full error message
• If applicable: Share screenshots/images of your problem
• If applicable: Share used input data

Please mark above checkboxes as following:

• Open
• Done

❌ Checkbox is not applicable to this bug report

input errors

raise error if invalid country or invalid year is entered

Automate black formatter

We could use

1. stickler as done in the windpowerlib or

2. commit](https://pre-commit.com/) as described on the black github repo.

Describe pvcompare parameters in readthedocs

This can be similar to the parameter description in MVS.

My proposal: @Piranias provides a description and @mahendrark creates the readthedocs page. The page should also include a link to the parameter description of MVS.

Explain default values of pvcompare in readthedocs

Default values being used in the simulation (incl. MVS parameters in csvs) should be stated and references (and calculations if applicable) given.

optimal PV cap >> optimal inverter cap

I don't find the issue now - maybe we just discussed - but @Piranias you once showed me a an output graphic of optimal additional installed capacites where the optimal PV capacity was much higher than the inverter capacity.
The reason for that or at least hints might be stated here rl-institut/multi-vector-simulator#2

Check badges build and coverage

[PV HP] Research on cost parameters heat pumps

• Cost parameters and lifetime of a heat pump need to be researched and added to the mvs_inputs_template_sector_coupling directory.
• After testing these parameters in simulations they need to be added to the documentation including references (section energyConversion.csv).

[PV HP] wrong definition of high/low temp reservoir

So far, the high temperature reservoir of heat pumps is defined by the room temperature instead of the flow temperature of the outflow (Vorlauftemperatur). This needs to be changed.
Can we find a way to derive the flow temperature from the room temperature?

Same accounts for the chiller: low temperature reservoir == room temperature

Then, also the documentation needs to be adapted here, section heat_pumps_and_chillers

Install MVS dev instead of master - or pypi package

Installing MVS dev branch seeems to work again: rl-institut/multi-vector-simulator#430

As we might change MVS to a pypi package soon, let's wait a few weeks to avoid double work. As long as we don't need changes in MVS dev we can keep the master installation.

normalized or absolute pv timeseries

option 1.) all timeseries are normalized for 1 kWp installed capacity. The development cost is also given for 1 kWp.

option 2.) all timeseries are given for a realistic module size. The costs are adapted individually for each module.

option 3.) all timeseries are scaled to a certain module area, e.g. 1m² The prices are also given for that area.

decision from 27. July (@Piranias , @SabineHaas ) : option 1

Add pero-si tests

scale SMARTS spectral irradiance to fit era5 ghi/dni

this is linked to #36

[CPV] add p_mp to cpv flateflate module and fix parameters

The i_mp and v_mp of the cpv flatplate module are set to 0 now. This needs to be changed, as well as all the other parameters, as soon as the flatplate module is measured by UPM.

are the investment costs allocated over the lifetime of the asset?

Hi,
the header already tells what this is about. I was wondering how the investmentcosts (especially opex_var in energyProduction) are allocated of the lifetime of the modules or the lifetime of the project?
Do you, @SabineHaas know how this is done in MVS?

Use complete_irradiance func of pvlib

We should use the complete_irradiance function of pvlib for calculating the dni instead of (ghi - dhi).

This functions calculates the missing irradiation column of dni, ghi, dhi if two of them are given.

Usage looks like this:
mc.complete_irradiance(weather=weather, times=weather.index)

Add PR template

[PV HP] definition of heating/cooling period

The cops/eers of heat pumps/chillers time series are calculated for a heating/cooling period, which are defined via temperatures in heat_pump_and_chillers.csv

The heating period starts at 17 degrees
Source: https://www.hotmaps-project.eu/wp-content/uploads/2018/03/D2.3-Hotmaps_for-upload_revised-final_.pdf

The problem I see is that the heat demand time series are never zero. So the cop time series does not match the heat demand time series.

additional info:
Here is a daily average temperature profile for NUTS-2 regions for residential sites for 2010 for all european countries: https://gitlab.com/hotmaps/hotmaps_task_2.7_temperature_profile_daily_avg_household_yearlong_2010

Adapt csvs according to MVS PR 347

There are API changes in the next MVS release. We need to adapt csvs and if necessary code to rl-institut/multi-vector-simulator#347

Costs for pero/si and cpv technologies

Hi,
In order to start reasonable simulations we need to estimate the costs for pero/si and cpv technologies. I know that @SabineHaas and @mahendrark, you worked on this before, right? What estimations can I can use for simulations, where are they documented?

Pero-Si: implement losses from cell -> module

I found that typical CTM losses (Cell to module) range from 1.2% - over 5 % depending on the irradiance and the cell type.

I would assume a constant loss for per-si cells of 5% for now. This is only a very vague guess and is not taking into account the CTM-loss dependency of irradiance/tmperature or architecture.

general Literature:
here

and here

Add era5 module to documentation

definition maximum power point

Hi,
I noticed that there might be a confusion with the definition of maximum power point. The nominal value is defined by:
nominal value = area / module_size * p_mp

right now p_mp is taken from module parameters at reference conditions. So it is the mpp at 25°C (that's how it is defined in pvlib).

But the nominal value should take the maximum possible pp at any weather conditions into account, right?

[documentation] update documentation of parameters

this needs to be updated: https://pvcompare.readthedocs.io/en/latest/parameters.html

as soon as all/most values are set

"label" in energyProduction causes error

I adapted this line in adapt_csv.py and suddenly an error is raised. I do not get the connection between the investment flow and the label of the asset. @SabineHaas do you have a clue what this is about?
If I manually change it back to the way you defined it here: "PV_si", "PV_cpv_180" and "PV_cpv_90" it works normal.

Here's the error message:

 File "/home/adminlocal/Dokumente/greco_env/lib/python3.6/site-packages/pyomo/core/expr/numvalue.py", line 230, in value
    % (obj.name,))
ValueError: No value for uninitialized NumericValue object InvestmentFlow.invest[Solar inverter (mono),Electricity bus]
ERROR: evaluating object as numeric value: InvestmentFlow.invest[Solar
    inverter (mono),Electricity bus]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
    No value for uninitialized NumericValue object InvestmentFlow.invest[Solar
    inverter (mono),Electricity bus]
14:04:54-ERROR-evaluating object as numeric value: InvestmentFlow.invest[Solar inverter (mono),Electricity bus]
    (object: <class 'pyomo.core.base.var._GeneralVarData'>)
No value for uninitialized NumericValue object InvestmentFlow.invest[Solar inverter (mono),Electricity bus]

travis build fails, csv's not found in site package

see ckecks in PR #70

[PV HP] Finish tests for heat pumps and chillers

Test function names do partly exist already in test_heat_pump_and_chiller.py.

[docs] links in code documentation need to be fixed

In the code documentation on readthedocs the links (and explanatory sentence) of the module demand does not work.
Probably the docstrings need to be adapted.

output: what does the storage flows show us?

Hi,
i noticed that the storage output is always less (about 80 %) of the storage input. Do you know why?

Also I was a little confused with this illustration. Do you know what levels the output flow to exactly 3780 kWh?

add check if timeseries(location, year) already exists

this is linked to #36

fix test_pv_feedin.setup_class()

The setup_class() function does not work. How can I debug test functions?

Make tests run without errors

If this is a travis issue this will be solved by @SabineHaas

parameter values: capex_var in energyConversion

The capex_var in energyConversion is set to 3000 Euro. In my csv and in the read the docs it says Euro/kW:
read the docs

in the link @mahendrark posted to the googledoc they propose an average price of 0.18 $/W which makes about 170 Euro/kW. How did you calculate the 3000 Euros?

read in specific energy_price for country

looking at this reference, i noticed that the energy price differs a lot between country (from 0.08 -0.3 Euro/kWh). I think we should probably write a function that reads in the specific energy price for that country.

@SabineHaas do you agree?

Fix dependency issues

There are several dependency issues when installing pvcompare which need to be looked into:

xarray 0.16.1 requires pandas>=0.25, but you'll have pandas 0.24.2 which is incompatible.
oemof 0.3.2 requires pyomo<5.7,>=4.4.0, but you'll have pyomo 5.7.1 which is incompatible.
greco-technologies 0.0.1 requires feedinlib==0.0.12, but you'll have feedinlib 0.1.0rc2 which is incompatible.
greco-technologies 0.0.1 requires xarray==0.15.0, but you'll have xarray 0.16.1 which is incompatible.

Check lifetime of inverter and charge controller

Check references https://pvcompare.readthedocs.io/en/latest/parameters.html
and values in csvs.

Adapt error raising tests

Let's use

with pytest.raises(XyzError):
    function_to_test()

for testing whether the expected error is risen. F.e. here, occurs in more tests.

parameter values: capex var in energyProduction

according to this reference, the costs of aquisition are calulated as follows:

for a system up to 10 kWp:

solar modules: 0,45 Euro - 0,90 Euro / Wp
solar inverter: ca 230 Euro/kW
cabels: 100 - 500 Euro
assembly robotics: 100 - 150 Euro/ kWp
installation: 200 Euro/ kWp
feedin-module: at least 150 Euro

makes 1.450 Euro/kWp with the inverter. Without inverter: ca. 1220 Euro/kWp. this is alot more than martha assumed (340 Euro/kWp)

Add python 3.8 to travis tests

Python version 3.8 was removed from testing on 15/07/20 as the tests were very slow. This seems to be okay for now during the developing phase.
This issue is a reminder to add the version again when less development work is going on.

Install MVS as pypi package (once it is released on pypi)

I will discuss about that with @Bachibouzouk

connected to MVS issue rl-institut/multi-vector-simulator#423

update function create_mvs_energy_production_file for cpv/perosi technologies and new costs

right now default values for a si module are inserted into energyProduction.csv if the number of columns differs from pv_setup. There should be either a warning saying that the energyProduction.csv is not correct or default values for different technologies should be available.

[Information] pvcompare is updated to latest MVS version

@Piranias @MaGering @c-moeller
I've just updated pvcompare to the latest MVS version and fixed the setup.py to provide a clean installation. see #81
Once MVS is released on pypi I will update the setup.py once more (#42). Then I think it's wise to work with a fixed MVS version and release or tag pvcompare once we want to update to a newer MVS version.

It's not merged into dev, yet. For installing pvcompare checkout the branch PR 81 and execute pip install -e . after navigating to the folder containing the setup.py.

Let me know in case of any installation problems or questions!
Have fun :)

parameter values: opex fix in energyProduction

Hi,
I just filled in all missing parameters from the docs into our csv's. With the values as they are in the docs only the electricity grid is used. I noticed that the opex_fix is set to 965 for our pv plants, so fix operational costs (€/kW/year). Where does this high number come from? shouldn't it be zero for pv plants? Or maybe the opex_fix was mixed up with capex_fix?

eventually if i set opex_fix to zero the pv_plants and the storage are used.

[Bug] ModuleNotFoundError: No module named 'greco_technologies.perosi.perosi'

I needed to delete the second "perosi" from the import import greco_technologies.perosi.perosi in pv_feedin.py to make it work in dev branch. Is this the same for you @Piranias ?

Checklist to make sure that the bug report ist complete:

• OS: ubuntu, 18.4
• Branch: dev, updated on 27th of July 20, 17:30
• If applicable: Attach full error message
• If applicable: Share screenshots/images o f your problem
• If applicable: Share used input data

Please mark above checkboxes as following:

• Open
• Done

❌ Checkbox is not applicable to this bug report

parameter values: energy_price in energyProviders

Hi,
so I added the new opex_fix to 140 Euro/kpW/year to our PV plants.
Still when running the simulation no PV components are used with the current settings. My guess is that we need to adapt the energy_price in energyProviders.

Here's what I found out from the simulation: the PV plants (only SI) are starting to be used only if energy_price is 0.5 or higher. if energy_price =also the cpv cells on the flat roof are beeing used.

@mahendrark did you already research on the enery price? is it fixed at 0.3 or is there a variance on the price?

@mahendrark @SabineHaas , so you have other ideas which parameters we could adapt to make the system running?

[Bug] Travis Ci conflicts installing gfortran compiler

Checklist to make sure that the bug report ist complete:

• OS: Ubuntu 18.04.5 LTS
• Branch: psi_test
• If applicable: Attach full error message
• [:x:] If applicable: Share screenshots/images of your problem
• [:x:] If applicable: Share used input data

Please mark above checkboxes as following:

• Open
• Done

❌ Checkbox is not applicable to this bug report

our code makes use of the fortran program SMARTS. Everything works fine on local machines, but Travis Ci seems to have problems with installing the fortran compiler gfortran (libgfortran4).

here's the travis.yml

see build

Error message:

(/lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.27' not found (required by /home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/greco_technologies/perosi/program.exe)``