fzj-iek3-vsa / hplib Goto Github PK

Somme heat pumps within the library have the ability for active cooling. In a first step, for air/water heat pumps, we want to

• filter the raw pdfs for heat pumps with cooling functionality
• create a database in output folder with relevant data
• implement and validate a fitting method
• extend the hplib_database.csv with cooling parameters
• extend the hplib.simulate() for cooling
• update documentation.ipynb

Another feature would be to implement passive cooling with brine/water heat pumps

As i try to clone the repository, i receive the following error message from git:

Are you aware of this or does this issue relates to my personal git setup?

Hi,
have you published any research papers on this work or any paper that use this library for any kind of applications (sizing of PV, BESS, HP, etc...) ?

Thank you for your great job.
Bye!

By now, the conversion from pdf to txt files is done with the command line tool pdftotext. There is an python-integration that could be used to have all functionality in the hplib-database.py and get rid of the bash script pdf2text.sh

see: https://pypi.org/project/pdftotext/

and: https://medium.com/@thibaultmonsel_4024/extract-text-from-pdf-with-python-python-pdf-processing-part-1-be875d76234b

Hello,

I was following the "documentation.ipynb" notebook, and everything was going smoothly until I reached Section 6.4.2 titled "Cooling" (under the "Validation" section). It seems the required output files were not created. I've gone through "hplib_database.py", and it appears that none of the functions are used to create the "database_cooling.csv" file which is used in functions related to cooling section.

Could someone assist in this? Or perhaps provide guidance in case I'm missing something?

Many thanks.

Hi @ttjaden,
great work to free the hp data and make it available for all kinds of modelling.
As an expert on open data licenses I would like to help to improve on the data publication.
At the moment, the resulting data is part of the repository and thus licensed under the MIT license.
While this is an excellent choice for the open-source software, it is not suitable for the resulting (open) data.

If you want to go deep into the open data licenses I can recommend this tutorial:

• https://openenergy-platform.org/tutorials/jupyter/tutorial_open-data-licenses/

As a tldr, I would recommend two license options:

1. CC-BY-4.0 a well known and standard open data license. Users only need to attribute correctly.
2. ODbL-1.0 an OSM-like copyleft license. When people use and extend the data, they need to share the improvements. Downside: it can prevent people from using it.

My personal view would be option 1 for this data set, because the list has been generated by a script, not a manual collection and extraction of the pdf data (correct me if I am wrong).

In addition I suggest to create a standardised metadata string that contains all necessary information in machine and human readable formats. The OEMetadata was developed for this purpose:

• https://openenergy-platform.org/tutorials/jupyter/OEMetadata/
• https://github.com/OpenEnergyPlatform/oemetadata/blob/develop/metadata/latest/template.json

I would be happy to assist you in creating the string, review and publish it.

Hi! Thanks for this valuable work. May I ask one easy question?
What is the
"Input temperature in °C at primary side of the heat pump"
and
"Output temperature in °C at secondary side of the heat pump"

I am trying to link this model with my ground source heat pump model, but too many heat exchangers and temperatures, so sorry I get lost for these two temperatures.

Thank you~

Currently with Github-Actions hplib-database.csv will not be moved to PyPI and are not pip installable.

For example the heatpump "CTC EcoAir 510M 1x230V" seems like it has a typing mistake in setpoint -7/52.
Possible: Check if the COP of Air/Water heat pump is constantly declining with higher delta T.

1. create output folder
2. move rename data_heatpumpkeymark.csv to output/hplib-database
3. commit code for heat pump model parameter identification and create output/hplib-parameter

By now, the generic version of each heat pump type (air/water, water/water, brine/water) represents an average model, beacause their parameters are the average of all available heat pump models.

For practical research question,

• 3 generic sub-categories should be created
• or a function the create the generic model on the user side.

The idea for the sub-categories could be:

• low efficiency (parameters for 20% of the worst real heat pump models)
• average effciency (parameters for the real heat pump models between low and high efficiency)
• high efficiency (parameters for 20% of the best real heat pump models)

The following column would help for research results visualisation

• eta_s
• SCOP

First of all let me say that this is a super important problem space and the library looks very useful. Thanks for writing it. I'm happy to have come across it and see it being actively developed. (And I have some cool ideas on what it could be used for..)

Anyway, I was trying to run the simulation snippet from 4.B Simulate a time series and ran into the following error:

File ~/Code/hplib/hplib/hplib.py:607, in HeatPump.simulate(self, t_in_primary, t_in_secondary, t_amb, mode, p_th_min)
    605             cop = p_th/p_el                           
--> 606 if cop <= 1:
    607     cop = 1
    608     p_el = self.p_th_ref

ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

I believe the code there should not be run if cop is an np.ndarray as that is already handled above.

I then looked a bit more at the code and would like to offer a few observations and make some suggestions for improving it:

It appears that the module hplib has both (1) a top-level simulate() method as well as (2) HeatPump.simulate() which appear to be quite similar but have some (I believe) undesired differences.

• None of the implementation code is shared. Are both methods really needed? If so can one just call the other?
• It would be good to have a unit test. E.g. that runs the examples from the Notebook.
• The docstring of (2) wrongly mentions parameters. That isn't actually a supported argument.
• Pytypes for t_in_primary and t_in_secondary are any for (1) but float for (2). I believe the correct type should be Union[float, numpy.ndarray].
• Minor: mode being an int makes the methods harder to use and the code harder to read. I believe an enum should be used here.

In the meantime, a lot of new models were added to the heatpump keymark.

• download and process new keymark pdf files
• define regular dates for updating the database
• write a short how-to on updating the database