wouterpeere / ghetool Goto Github PK

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.

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

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.

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.

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.

Hi @wouterpeere,

Sometimes the wrong options are shown for the selected options. This issue seems to be fixed by show and hide the linked options if the main options is shown/hidden.

With best regards
@tblanke

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.

Hi @wouterpeere ,

I have heard from people in Germany that we normally run simulations for 50 years. We need this as well for applications. What do you think about this? Do you need 20 years in Belgium?

With best regards
@tblanke

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

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.

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?

Hi @wouterpeere,

I have added a Navigation Toolbar to the figures.
Maybe then the save Figure button is obsolet then.

With best regards
@tblanke

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

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.

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

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

Is being implemented in separate branch

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.

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).

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

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.

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.

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.

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.

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.

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

In the latest version of the RTD, the bullet points are no longer shown (e.g. https://ghetool.readthedocs.io/en/latest/sources/changelog.html compared to https://ghetool.readthedocs.io/en/v2.1.0/sources/changelog.html). This issue has as goal to find out why the bullet points disappeared and bring them back for the release of v2.1.1.

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.

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)

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.

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.

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?

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

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.

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.

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)

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.

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.

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.

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

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.

@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.

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)

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.

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.

Adding a read the docs docmentation to GHEtool. For a much better documentation.

Change the dataset to json instead of pickle dump.

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.