Giter Site home page Giter Site logo

wouterpeere / ghetool Goto Github PK

View Code? Open in Web Editor NEW
25.0 5.0 10.0 299.46 MB

GHEtool is an open-source tool for borefield sizing and ground temperature evolution plotting.

Home Page: https://ghetool.eu

License: BSD 3-Clause "New" or "Revised" License

Python 98.98% TeX 1.02%
geothermal-energy borefields sizing energy storage geothermal

ghetool's Introduction

GHEtool: An open-source tool for borefield sizing

PyPI version Conda version Tests codecov DOI Downloads Downloads Read the Docs

What is GHEtool?

GHEtool is a Python package that contains all the functionalities needed to deal with borefield design. GHEtool has been developed as a joint effort of KU Leuven (The SySi Team), boydens engineering (part of Sweco) and FH Aachen and is currently being maintained by Enead BV. The core of this package is the automated sizing of borefield under different conditions. By making use of combination of just-in-time calculations of thermal ground responses (using pygfunction) with intelligent interpolation, this automated sizing can be done in the order of milliseconds. Please visit our website https://GHEtool.eu for more information.

Read The Docs

GHEtool has an elaborate documentation were all the functionalities of the tool are explained, with examples, literature and validation. This can be found on https://docs.ghetool.eu.

Graphical user interface

There are two graphical user interfaces available which are built using GHEtool: GHEtool Pro and GHEtool Community

GHEtool Pro

GHEtool Pro is the official and supported version of GHEtool which supports drilling companies, engineering firms, architects, government organizations in their geothermal design process. With GHEtool Pro they can minimize the environmental and societal impact while maximizing the cost-effective utilization of geothermal projects. Visit our website at https://ghetool.eu to learn more about the synergy between this open-source package and GHEtool Pro.

GHEtool Community

Besides GHEtool Pro, an open-source alternative for the graphical user interface is available in the form of GHEtool Community. This version is built and maintained by the community, and has no official support like GHEtool Pro. You can read all about this GHEtool Community on their GitHub repo.

Development

GHEtool is in constant development with new methods, enhancements and features added to every new version. Please visit our project board to check our progress.

Requirements

This code is tested with Python 3.8, 3.9, 3.10, 3.11 and 3.12 and requires the following libraries (the versions mentioned are the ones with which the code is tested)

  • matplotlib >= 3.5.2
  • numpy >= 1.23.1
  • pandas >= 1.4.3
  • pygfunction >= 2.2.1
  • scipy >= 1.8.1

For the tests

  • Pytest >= 7.1.2

For the active/passive example

  • scikit-optimize >= 0.9.0

Quick start

Installation

One can install GHEtool by running Pip and running the command

pip install GHEtool

or one can install a newer development version using

pip install --extra-index-url https://test.pypi.org/simple/ GHEtool

GHEtool is also available as a conda package. Therefore, you can install GHEtool with the command:

conda install GHEtool

Developers can clone this repository.

It is a good practise to use virtual environments (venv) when working on a (new) Python project so different Python and package versions don't conflict with eachother. For GHEtool, Python 3.8 or higher is recommended. General information about Python virtual environments can be found here and in this article.

Check installation

To check whether everything is installed correctly, run the following command

pytest --pyargs GHEtool

This runs some predefined cases to see whether all the internal dependencies work correctly. All test should pass successfully.

Get started with GHEtool

Building blocks of GHEtool

GHEtool is a flexible package that can be extend with methods from pygfunction. To work efficiently with GHEtool, it is important to understand the main structure of the package.

Borefield

The Borefield object is the central object within GHEtool. It is within this object that all the calculations and optimizations take place. All attributes (ground properties, load data ...) are set inside the borefield object.

Ground properties

Within GHEtool, there are multiple ways of setting the ground data. Currently, your options are:

  • GroundConstantTemperature: if you want to model your borefield with a constant, know ground temperature.

  • GroundFluxTemperature: if you want to model your ground with a varying ground temperature due to a constant geothermal heat flux.

  • GroundTemperatureGradient: if you want to model your ground with a varying ground temperature due to a geothermal gradient.

  • You can also use multiple ground layers to define your ground model. Please take a look at our example.

Please note that it is possible to add your own ground types by inheriting the attributes from the abstract _GroundData class.

Pipe data

Within GHEtool, you can use different structures for the borehole internals: U-tubes or coaxial pipes. Concretely, the classes you can use are:

  • Multiple U-tubes
  • Single U-tubes (special case of multiple U-tubes)
  • Double U-tubes (special case of multiple U-tubes)
  • Coaxial pipe

Please note that it is possible to add your own pipe types by inheriting the attributes from the abstract _PipeData class.

Fluid data

You can set the fluid data by using the FluidData class. In the future, more fluid data classes will be made available.

Load data

One last element which you will need in your calculations, is the load data. Currently, you can only set the primary (i.e. geothermal) load of the borefield. In a future version of GHEtool, also secundary building loads will be included. For now, you can use the following inputs:

  • MonthlyGeothermalLoadAbsolute: You can set one the monthly baseload and peak load for heating and cooling for one standard year which will be used for all years within the simulation period.
  • HourlyGeothermalLoad: You can set (or load) the hourly heating and cooling load of a standard year which will be used for all years within the simulation period.
  • HourlyGeothermalLoadMultiYear: You can set (or load) the hourly heating and cooling load for multiple years (i.e. for the whole simulation period). This way, you can use secundary loads already with GHEtool as shown in this example.
  • MonthlyGeothermalLoadMultiYear: You can set the monthly heating and cooling load for multiple years (i.e. for the whole simulation period).

All load classes also have the option to add a yearly domestic hot water usage.

Please note that it is possible to add your own load types by inheriting the attributes from the abstract _LoadData class.

Options for sizing methods

Like always with iterative methods, there is a trade-off between speed and accuracy. Within GHEtool (using the CalculationSetup class) one can alter different parameters to customize the behaviour they want. Note that these options are additive, meaning that, for example, the strongest criteria from the atol and rtol is chosen when sizing. The options are:

  • atol: For the sizing methods, an absolute tolerance in meters between two consecutive iterations can be set.
  • rtol: For the sizing methods, a relative tolerance in meters between two consecutive iterations can be set.
  • max_nb_of_iterations: For the sizing methods, a maximum number of iterations can be set. If the size is not converged, a RuntimeError is thrown.
  • use_precalculated_dataset: This option makes sure the custom g-function dataset (if available) is not used.
  • interpolate_gfunctions: Calculating the gvalues gives a large overhead cost, although they are not that sensitive to a change in borehole depth. If this parameter is True it is allowed that gfunctions are interpolated. (To change the threshold for this interpolation, go to the Gfunction class.)
  • deep_sizing: An alternative sizing method for cases with high cooling (peaks) and a variable ground temperature. This method is potentially slower, but proves to be more robust.
  • force_deep_sizing: When the alternative method from above should always be used.

Simple example

To show how all the pieces of GHEtool work together, below you can find a step-by-step example of how, traditionally, one would work with GHEtool. Start by importing all the relevant classes. In this case we are going to work with a ground model which assumes a constant ground temperature (e.g. from a TRT-test), and we will provide the load with a monthly resolution.

from GHEtool import Borefield, GroundDataConstantTemperature, MonthlyGeothermalLoadAbsolute

After importing the necessary classes, the relevant ground data parameters are set.

data = GroundDataConstantTemperature(3,   # ground thermal conductivity (W/mK)
                                     10,  # initial/undisturbed ground temperature (deg C)
                                     2.4*10**6) # volumetric heat capacity of the ground (J/m3K) 

Furthermore, for our loads, we need to set the peak loads as well as the monthly base loads for heating and cooling.

peak_cooling = [0., 0, 34., 69., 133., 187., 213., 240., 160., 37., 0., 0.]   # Peak cooling in kW
peak_heating = [160., 142, 102., 55., 0., 0., 0., 0., 40.4, 85., 119., 136.]  # Peak heating in kW

monthly_load_heating = [46500.0, 44400.0, 37500.0, 29700.0, 19200.0, 0.0, 0.0, 0.0, 18300.0, 26100.0, 35100.0, 43200.0]        # in kWh
monthly_load_cooling = [4000.0, 8000.0, 8000.0, 8000.0, 12000.0, 16000.0, 32000.0, 32000.0, 16000.0, 12000.0, 8000.0, 4000.0]  # in kWh

# set load object
load = MonthlyGeothermalLoadAbsolute(monthly_load_heating, monthly_load_cooling, peak_heating, peak_cooling)

Next, we create the borefield object in GHEtool and set the temperature constraints and the ground data. Here, since we do not use a pipe and fluid model (see Examples if you need examples were no borehole thermal resistance is given), we set the borehole equivalent thermal resistance.

# create the borefield object
borefield = Borefield(load=load)

# set ground parameters
borefield.set_ground_parameters(data)

# set the borehole equivalent resistance
borefield.Rb = 0.12

# set temperature boundaries
borefield.set_max_avg_fluid_temperature(16)  # maximum temperature
borefield.set_min_avg_fluid_temperature(0)  # minimum temperature

Next we create a rectangular borefield.

# set a rectangular borefield
borefield.create_rectangular_borefield(10, 12, 6, 6, 110, 4, 0.075)

Note that the borefield can also be set using the pygfunction package, if you want more complex designs.

import pygfunction as gt

# set a rectangular borefield
borefield_gt = gt.boreholes.rectangle_field(10, 12, 6, 6, 110, 1, 0.075) 
borefield.set_borefield(borefield_gt)

Once a Borefield object is created, one can make use of all the functionalities of GHEtool. One can for example size the borefield using:

depth = borefield.size()
print("The borehole depth is: ", depth, "m")

Or one can plot the temperature profile by using

borefield.print_temperature_profile(legend=True)

A full list of functionalities is given below.

Functionalities

GHEtool offers functionalities of value to all different disciplines working with borefields. The features are available both in the code environment and in the GUI. For more information about the functionalities of GHEtool, please visit the documentation on https://docs.ghetool.eu.

License

GHEtool is licensed under the terms of the 3-clause BSD-license (see GHEtool license). For professional licenses, contact us at [email protected].

Contact GHEtool

  • Do you want to support GHEtool financially or by contributing to our software?
  • Do you have a great idea for a new feature?
  • Do you have a specific remark/problem?

Please do contact us at [email protected].

Citation

Please cite GHEtool using the JOSS paper.

Peere, W., Blanke, T.(2022). GHEtool: An open-source tool for borefield sizing in Python. Journal of Open Source Software, 7(76), 4406, https://doi.org/10.21105/joss.04406

For more information on how to cite GHEtool, please visit the ReadTheDocs at https://docs.ghetool.eu.

References

Development of GHEtool

Coninx, M., De Nies, J., Hermans, L., Peere, W., Boydens, W., Helsen, L. (2024). Cost-efficient cooling of buildings by means of geothermal borefields with active and passive cooling. Applied Energy, 355, Art. No. 122261, https://doi.org/10.1016/j.apenergy.2023.122261.

Peere, W., Hermans, L., Boydens, W., and Helsen, L. (2023). Evaluation of the oversizing and computational speed of different open-source borefield sizing methods. In Proceedings of International Building Simulation Conference 2023. Shanghai (Belgium), 4-6 September 2023.

Coninx, M., De Nies, J. (2022). Cost-efficient Cooling of Buildings by means of Borefields with Active and Passive Cooling. Master thesis, Department of Mechanical Engineering, KU Leuven, Belgium.

Peere, W., Blanke, T. (2022). GHEtool: An open-source tool for borefield sizing in Python. Journal of Open Source Software, 7(76), 4406, https://doi.org/10.21105/joss.04406

Peere, W., Picard, D., Cupeiro Figueroa, I., Boydens, W., and Helsen, L. (2021). Validated combined first and last year borefield sizing methodology. In Proceedings of International Building Simulation Conference 2021. Brugge (Belgium), 1-3 September 2021. https://doi.org/10.26868/25222708.2021.30180

Peere, W. (2020). Methode voor economische optimalisatie van geothermische verwarmings- en koelsystemen. Master thesis, Department of Mechanical Engineering, KU Leuven, Belgium.

Applications/Mentions of GHEtool

Meertens, L. (2024). Invloed van dynamische korte-termijneffecten op de dimensionering van geothermische boorvelden. Master thesis, Department of Mechanical Engineering, KU Lueven, Belgium.

Weynjes, J. (2023). Methode voor het dimensioneren van een geothermisch systeem met regeneratie binnen verschillende ESCO-structuren. Master thesis, Department of Mechanical Engineering, KU Leuven, Belgium.

Hermans, L., Haesen, R., Uytterhoeven, A., Peere, W., Boydens, W., Helsen, L. (2023). Pre-design of collective residential solar districts with seasonal thermal energy storage: Importance of level of detail. Applied thermal engineering 226, Art.No. 120203, 10.1016/j.applthermaleng.2023.120203

Cimmino, M., Cook., J. C. (2022). pygfunction 2.2 : New Features and Improvements in Accuracy and Computational Efficiency. In Proceedings of IGSHPA Research Track 2022. Las Vegas (USA), 6-8 December 2022. https://doi.org/10.22488/okstate.22.000015

Verleyen, L., Peere, W., Michiels, E., Boydens, W., Helsen, L. (2022). The beauty of reason and insight: a story about 30 years old borefield equations. IEA HPT Magazine 40(3), 36-39, https://doi.org/10.23697/6q4n-3223

Peere, W., Boydens, W., Helsen, L. (2022). GHEtool: een open-sourcetool voor boorvelddimensionering. Presented at the 15e warmtepompsymposium: van uitdaging naar aanpak, Quadrivium, Heverlee, België.

Peere, W., Coninx, M., De Nies, J., Hermans, L., Boydens, W., Helsen, L. (2022). Cost-efficient Cooling of Buildings by means of Borefields with Active and Passive Cooling. Presented at the 15e warmtepompsymposium: van uitdaging naar aanpak, Quadrivium, Heverlee, België.

Peere, W. (2022). Technologieën voor de energietransitie. Presented at the Energietransitie in meergezinswoningen en kantoorgebouwen: uitdagingen!, VUB Brussel Bruxelles - U Residence.

Sharifi., M. (2022). Early-Stage Integrated Design Methods for Hybrid GEOTABS Buildings. PhD thesis, Department of Architecture and Urban Planning, Faculty of Engineering and Architecture, Ghent University.

Coninx, M., De Nies, J. (2022). Cost-efficient Cooling of Buildings by means of Borefields with Active and Passive Cooling. Master thesis, Department of Mechanical Engineering, KU Leuven, Belgium.

Michiels, E. (2022). Dimensionering van meerdere gekoppelde boorvelden op basis van het type vraagprofiel en de verbinding met de gebruikers. Master thesis, Department of Mechanical Engineering, KU Leuven, Belgium.

Vanpoucke, B. (2022). Optimale dimensionering van boorvelden door een variabel massadebiet. Master thesis, Department of Mechanical Engineering, KU Leuven, Belgium.

Haesen R., Hermans L. (2021). Design and Assessment of Low-carbon Residential District Concepts with (Collective) Seasonal Thermal Energy Storage. Master thesis, Departement of Mechanical Engineering, KU Leuven, Belgium.

ghetool's People

Contributors

kyleniemeyer avatar nmstreethran avatar tblanke avatar wouterpeere avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

ghetool's Issues

Sizing with variable mass flow rate

The effective borehole thermal resistance is a function of the mass flow rate. It can be useful, whenever a peak occurs, to go to a more turbulent fluid regime in order to decrease the thermal resistance and hence make it feasible to size the borefield smaller. This however comes at a higher pumping cost.

This optimisation, based on the work of (Vanpoucke, 2022) will be implemented in GHEtool.

Problem with print_temperature_profile with L3/L4 sizing

Currently, when sizing a borefield with L3 and L4, whenever the field is limited in either the first quadrant (limited in the first year by cooling) or second quadrant (limited in the last year, by cooling) the function print_temperature_profile will give a False result.
This is due to the fact that GHEtool is programmed this way that it minimises the number of times the temperature profile is calculated.

This will be fixed in version v2.1.1, but in v2.1.0 it can be solved by setting the 'recalculate' variable in print_temperature_profile to 'True' when plotting the temperature profile.

Include short-term effects in sizing

Right now, GHEtool ignores the internal capacity of the borehole, by making use of the equivalent borehole thermal resistance. This short-term effects however, can play an important role in some cases.

A resistance-capacitance model can be implemented like the one from (Minaei and Maerefat, 2017).

New calculation method for the sizing by temperature profile method

I have implemented a new calculation method for the sizing by temperature profile method. It is just considering the temperature in the first and last year of the borefield.

A new branch (wouterpeere/GHEtool/issue44-new-calulation-method) and a pytest (test_new_calc_method.py) to show the speed improvements have been implemented.

Combined active and passive cooling

The methodology, developed in Coninx M., De Nies J. (2022) will be implemented in GHEtool. This methodology allows to size the borefield taking into account both active and passive cooling

Custom README for PyPi

It can be usefull to create a custom README for PyPi since the links currently do not work.

Regeneration

Oftentimes, there is a problem with imbalance when designing borefields.
We will implement a method to size with regeneration in mind (e.g. dry cooler/solar thermal collectors)

Permission error

When running the program twice from the gui (win 10), I get a permission error:
PermissionError: [Errno 13] Permission denied: 'backup.pkl'

Steps to reproduce the behavior:

  1. install GHEtool gui (win 10)
  2. run GHetool gui
  3. click on 'Calculate current scenario' -> results shown fine
  4. click on 'Calculate current scenario' again (no additional actions) -> crash, application closes (see screenshot in attachment)

XhvR4A22IE

No error when field is too large

Sometimes, the algorithm gives a result even though the solution is not converged. This is the case with field which are deeper than the precalculated data.
This will be fixed in the near future and will be totally gone when in v2.1.0 the JIT gfunction calculation will be in place.

Accurate sizing method

Implement a more accurate sizing method which iterates until the temperature converges to the limit. Now, the simplified sizing converges 'without looking' at the temperature.

Depth <1m

Sometimes, due to the iterative nature of the depth calculation, one iteration step requires a depth <1m. The program then crashes, sinces 1m is the minimal depth.

We will add a check for this to say that the depth should at least be 1m. If it keeps converging towards a smaller value, we will return an error.

Pytest keeps running

When running pytest on the speed_comparison validation, it seems to keep running sometimes (see actions in GitHub). This, most likely, has to do with the new GFunction class.
This behaviour should be investigated further.

Recreate GUI

Currently, the GUI has been developed with Qt designer, but due to licensing issues, it is not possible to share the files that create the gui you can find in the repo. This makes it not easy for the community to change and adapt the GUI itself.

Since a large restructuring of the GUI is planned (due to new implementations in GHEtool), we can think about rewriting the whole thing using e.g. PySimpleGUI which will make it easier to implement new changes directly to the api-version of GHEtool and the GUI itself.

Temperature gradient is wrong by factor 2

Hi @wouterpeere

The temperature gradient in the gui of for example 3 K/100 m is leading to an average ground temperature of 13 °C if a 10 °C ground temperature is selected. I think this should be 11.5 °C.
I have created a new branch for this. So if i am right you can just create a pull request.

With best regards
@tblanke

Include different peak lengths for heating and cooling

It can be useful to include different peak lengths for heating and cooling separately.
This was already mentioned in issue #44 but it will be moved towards this issue.

Implementing this, has an impact on

  • L2 sizing
  • Temperature plotting
  • L3/L4 sizing
  • GUI
  • Tests

Use borefield class from pygfunction

Currently, the GroundData class contains ground parameters (like thermal conductivity and ground volumetric heat capacity) but also the dimensions of the borefield.

Since GHEtool is moving away from the precalculated data towards just-in-time calculation (see issues #23 and #12), a borefield model is always needed. It would simply the code a lot to make sure users create a borefield model in pygfunction and set this in GHEtool.

Speed improvement in sizing with jit

When using jit for the sizing of borefields, every iteration, every borehole inside the borefield should be updated to a new length in order to calculate the gfunctions. For larger borefields, this can take up some time.

The goal of this issue is to investigate whether or not the time required to update the borefield model is significant in comparison to the gfunction calculation itself.

Speed improvements

There are a couple of speed improvements that can be done to improve the speed of the code.

  • Implement numpy arrays everywhere
  • Use numpy.sum instead of using functools.reduce()
  • Use concatenated lists for the temperature profiles instead of iterating over lists
  • Use convolution (scipy.signal.fftconvolve) instead of using multiple matrix multiplications in numpy

Speed improvements in optimise load profile

Currently, every iteration in optimise_load_profile() requires the calculation of the fluid temperature, which requires the calculation of gfunction values. However, in this particular function, the size of the borefield is always constant thus so are the gfunctions.

Related to issue #57 the creation of a gfunction class can overcome this problem by checking if the requested gvalues are already calculated so they are not calculated again.

[JOSS Review] Paper comments

@wouterpeere I'm the other reviewer of the JOSS paper, and here is some feedback on the paper. There some fairly minor things in two areas.

  • Statement of Need: The sentence here "This sector should decarbonize to reach the climate goals in 2050." is a command because of the way "should" is used and the use of 2050 calls for a reference. If there is a desire to keep the specific year of 2050 in the text, there needs to be a reference or further explanation as to what is contemplated by 2050. This can be avoided if this sentence is changed to something like "In order to achieve meaningful climate goals, it is likely that progress toward decarbonization of the building sector is required.", then there's no need for an additional reference and it's no longer a command. The following sentence might also need to be adjusted a bit so that there's agreement as to whether there's a singular "goal" or it's plural "goals"
  • References: The reference here to the IGSHPA website is a bit confusing when the company has a website at groundloopdesign.com. It would be better to link directly to the company website rather than link to a website that links to the company website.

Depreciated gfunction.uniform_temperature from pygfunction

Currently, in the function createCustomDataset, the function 'uniform_temperature' from pygfunction is used. This will however be depreciated in pygfunction v3.0. This has to be changed to use the pygfunction.gfunction.gFunction class.

smaller simulation periods did not work

here the error message:
File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\interpolate\interpolate.py", line 2675, in interpn
raise ValueError("There are %d points and %d values in "
ValueError: There are 74 points and 76 values in dimension 3

Hourly sizing method

A new hourly sizing method (L4 method) will be implemented and the example/validation files (w.r.t. the different sizing methods) will be updated to include this methodology. See branch L4_sizing.

Backwards compatibility

Currently, when working with the gui, a newer version of GHEtool can cause problems when loading *.GHEtool files from a previous version, due to the fact that variables in the main_class can be changed. This can cause annoying issues.

This issue relates to the question whether or not it is possible to add a 'conversion' function to convert files created with one version of GHEtool to a newer version. Perhaps the version of GHEtool can be saved in the *.GHEtool file itself so it can be read and used as an input to do the conversion?

TRT implementation

Currently, one can put in GHEtool a constant equivalent borehole thermal resistance (coming from a TRT test for example) but one cannot calculate this within GHEtool itself given measurement data.
It would be nice if the Rb* calculation can happen within GHEtool itself using the TRT measurement data.

Delete precalculated data?

With the new implementation of the g-function calculation within pygfunction, it is very fast to size a borefield. Currently, the whole precalculated dataset is around 100MB.

It would be an option to exclude the precalculated dataset in GHEtool and calculate the g-functions just-in-time. For single sizings, this effect in speed will be hard to notice. We can provide an option to precalculate g-functions for situations/calculations where a lot of iterations are needed.

Size by length and width - JIT g-function

Currently, the size_by_length_and_width function only works with the precalculated data, which means that it is limited to 20x20 borefields. Although just-in-time calculation is included in v2.0.7, this would be very slow in this function, due to the way it is programmed.

  • An enhancement would be to rewrite this function so it can take advantage of this JIT calculation so it can take into account fields larger than 20x20 boreholes.
  • Currently, this function also does use the possibility of having an dynamic Rb* calculated

Shown borehole resistance on borehole resistance page

Currently, when using the gui with a dynamically calculated effective borehole thermal resistance, this resistance is only shown on the result page. It would be nice if this result could be shown on the page on borehole thermal resistance so changes to borehole parameters can immediately be evaluated.

Add flexible temperature limits

It would be nice to have the possibilty to change the min and max temperature from fix values to some which are different for every month.

Build exe documentation?

It can be useful to add the setupfiles to compile the GUI to an exe in the repository and to also add some information about this in the README.

Two data folders

There is a data folder under the main folder with *.pickle documents and one under the GUI folder with *.py documents. Why this duplication?

[JOSS Review] Functionality + documentation

Hi @wouterpeere, I'm one of the reviewers assigned to your submission to JOSS (openjournals/joss-reviews#4406). I'm opening this issue as part of my review; it concerns the functionality and documentation of GHEtool. The headings below correspond to items in my review checklist. Please let me know if anything is unclear. Thanks.

Installation / installation instructions

Does installation proceed as outlined in the documentation?
Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.

The installation instruction is currently limited to the quick start using pip, and it states that "Developers can clone this repository". I highly recommend including some additional steps here (such as cloning the repository and using a virtual environment) to help users new to Python.

Could you also add a link or badge to the PyPI package in the README?

Functionality / functionality documentation

Have the functional claims of the software been confirmed?
Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?

Functionality documentation seems to be missing. Sufficient API documentation is required, and the core API should be documented at the very least. You can add this to the README.

Automated tests

Are there automated tests or manual steps described so that the functionality of the software can be verified?

I can't seem to find any tests. Have you implemented any tests and what are the steps to run them? I see that you have some scripts in the GHEtool/Validation folder. The testing instructions should be clearly stated so that users can determine whether the functions work after installing the software.

Example usage

Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).

You have included examples in the GHEtool/Examples folder. Can you link each of these scripts to the list of functionalities of the software in the README, and add simple instructions on how users can run these scripts?

Variable ground temperature

Currently, the temperature used for the borefield sizing is constant. This is an assumption, for the temperature is a function of the depth. If, when sizing, the range of depths is not as high, this effect is negligible. However, a variable temperature will be implemented in a next update of GHEtool.

Custom gfunction calculation in GUI

In issue #57 a custom gfunction class is developed for precalculating gfunction values. This takes some time, but afterwards sizing (and more computational expensive aims like optimise load profile) will be significantly faster.

The idea is to let the gui calculate this custom gfunction class in the background (and this should be recalculate whenever the borefield dimensions change) and load it into the ds.borefield class when the calculation button is pressed.

This gfunction class should however be saved seperately in the datastorage object, since the borefield object in the datastorage is resetted each time the calculation is started.

This task can be started once v2.1.1 is released.

Restructure package

Currently, all the functionalities of GHEtool are placed in the main_class.py, with a few variable classes.

Since the number of functionalities of GHEtool is increasing, a new structure is needed in order to cope with this changes.
This issue is related to this task.

The idea is to split the main_class.py into a Borefield, GeothermalSystem and HybridGeothermalSystem class, each extending on the previous class.

  • The Borefield class will contain all the information about borefield sizing from the borefield perspective itself.
  • The GeothermalSystem class takes the heat pumps into account, so there can be accounted for variable COP's. Also the functionality to optimise the load profile will be moved to this class, since it works with the geothermal system and not so much the borefield itself. The active- and passive cooling functionality will be implemented here.
  • The HybridGeothermalSystem class will move towards a hybridisation of the system. E.g. regeneration will be taken into account here.

Furthermore, up until now, everything related to g-functions has been part of the main_class.py. This will also be moved to a seperate class to improve readability.

Changing sizing methods

When a sizing method is changed in setup_sizing an error occurs after the sizing, due to the fact that now two sizing methods are active.

Bug spacing

Hello Wouter. I seem to be having a bug when the dataset is being generated. I did a simulation with a 2x1 field and asked the GHEtool to calculate the necessary depth. When the boreholes are 8,9m apart, the precalculated databases is used and the depth is as expected (about 130m for a family home). When I then ask the software to put the boreholes at 10m apart, the dataset is being genereated, but the calulated depth is aproximately half of this 130m. I might be doing something wrong, but the onlyt thing I did was copy the first scenario and change the distance between the boreholes. The first scenario (with the precalculated data) als fits with what Smartgeotherm calculates, so that looks fine. Might it be that with the newley generated dataset, the calculated length per well is afterwards divided by the total number of boreholes? Kind regard, and thanks for making this software

Originally posted by @blcools in #12 (comment)

Stuck in loop when sizing with variable Tg

When sizing with a variable Tg, the sizing can become stuck in an infinite loop when the field is limited by the maximum temperature.

This is due to the fact that in order to make sure that the field does not exceed this maximum temperature, the field size should be larger, meaning: deeper. This however increases also the main temperature, which can lead to a runaway iteration.

This can be solved by including a specific error message for this problem.

Reduce hourly to monthly

When importing an hourly load and converting it to a monthly one, there is a small mismatch in loads due to a false index in _reduce_hourly_to_monthly.

Create gfunction class

It can be beneficial to create a seperate gfunction class instead of calculating the gfunctions within the main_class.
This is related to issue #45 and #56 .

The idea is to create two classes:

  • a small 'custom gfunction' class where the gfunction calculation happens based on interpolation between precalculated data. This class will also have the functionality to save the custom gfunction in a pickle dump.
  • a 'JIT gfunction' class, which does basically everything the gfunction calculation within the main_class does right now. Here, before calculating the gfunctions, the class can check whether or not the requested gfunctions (issue #56 ) where already calculated in the past, so they should not be calculated again. Also an option is to save the calculated gfunctions for different depths, so it can choose between calculating them JIT or interpolating them based on already calculated data.

Add Coaxial Pipes

Add the possibilty to calculate borehole resistances also for coaxial pipes.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.