j-c-cook / ghedt Goto Github PK

https://stackoverflow.com/a/33619018

Hotel, office and school loads at a range of locations.

The version in setup and the CHANGELOG should be edited to reflect that version 0.1 is released.

The gif in the README file is 756 KB and the atlanta loads file that is stored in two locations is 96 KB. The goal of this issue is to reduce the size of the package so that when compressed it will be less than 20 MB.

The higher level Design API is currently capable of the near-square, rectangular, bi-rectangular and bi-zoned search routines. However, Cook (2021) showcased more advanced capabilities of ghedt such as the bi-rectangular design routine with no-drilling zones (section 4.4.4 pages 143-146) and the bi-uniform polygonal constrained rectangular search with no-drilling zones (section 4.4.5, pages 146-148). While ghedt can currently perform the more advanced routines, the Design object will do much of the heavy lifting.

The purpose for this issue is to increase the functionality of the Design object to handle the even more advanced routines.

Running examples/Design/find_near_square.py is throwing me an AttributeError for length_of_side on line 132. It seems like everything is in order to me, inside of utilities.py but the error is there, nonetheless.
File ".\find_near_square.py", line 132, in main length = dt.utilities.length_of_side(number_of_boreholes, B) AttributeError: module 'ghedt.utilities' has no attribute 'length_of_side'

Initially upon running Clg-10pct.csv in the near_square.py design example file, I got the following message:

ValueError: Based on the loads provided, the excess temperatures for the minimum and maximum number of boreholes falls above 0. This means that the loads are "astronomical" or that the higher end of the domain needs to contain more boreholes. Consider increasing the available land area, or decreasing the minimum allowable borehole spacing.

This error was correct. A new issue needs to address the fact that the Design interface has a hard coded 1x1 to 32x32 range for the near_square search in the following lines:

After modifying the 32 to be 64 I could get the program to throw the error @mitchute mentions (He may be using a routine that allows him to define a land area, or perhaps he did the same thing using the near-square search). A new issue will need to address this hard-coded value.

Originally posted by @j-c-cook in #79 (comment)

Add the ability to compute g-functions with the equivalent method and unequal segments set as default.

The gFunctionDatabase is no longer necessary based the developments of Prieto and Cimmino (2021).

The following function needs to be completed. The function will set the shank spacing based on A, B or C options defined in Paul's MS thesis.

@mitchute mentions that the shank spacing s value in ghedt should be further clarified:

https://gist.github.com/mitchute/151522d67cdc21058ac523881f4e7957?permalink_comment_id=4049526#gistcomment-4049526

The PLAT should become a sub-package of ghedt, rather than maintaining its own installation instruction set.

For ghedt to integrate into the online techno-economic tool, there needs to be a design_from_file() function. The GHEDT input file should contain a version number.

Traceback (most recent call last):
File "..................................................................................................../ghedt/examples/Design/find_bi_zoned_rectangle.py", line 230, in
main()
File "..................................................................................................../ghedt/examples/Design/find_bi_zoned_rectangle.py", line 151, in main
bisection_search = design_single_u_tube.find_design(disp=True)
File "....................................................................................................\ghedt\design.py", line 85, in find_design
bisection_search = dt.search_routines.BisectionZD(
File "....................................................................................................\ghedt\search_routines.py", line 261, in init
Bisection1D.init(
File "....................................................................................................\ghedt\search_routines.py", line 44, in init
g_function = dt.gfunction.compute_live_g_function(
File "....................................................................................................\ghedt\gfunction.py", line 92, in compute_live_g_function
gfunc = calculate_g_function(
File "....................................................................................................\ghedt\gfunction.py", line 44, in calculate_g_function
segment_ratios = gt.utilities.segment_ratios(
AttributeError: module 'pygfunction.utilities' has no attribute 'segment_ratios'

The routines in search_routines.py currently can only accept a per borehole flow rate. This issue is to enhance the API to add the ability to define flow rate on either a borehole or system basis.

This package is fairly large. The goal here is to work on the documentation throughout to provide users with an understanding of how things are organized and how to help further the package.

To help with future potentially more complex optimization that considers a mixture of series and parallel connected boreholes, ghedt should utilize the network class.

When running the attached loads, I'm seeing an interpolation out-of-range error in perform_current_month_simulation function, here:

Calling from the Bisection1D search routine, and setting a breakpoint at line 440 of that function, I'm seeing

max(dT_fluid_pk) = 12.208312117009044
dT_fluid_nm_max = 27.59003818526601
min(dT_fluid_pk) = 0.0

Thus causing the out-of-bounds interpolation error. It's unclear currently what the underlying issue is.

4509.csv

GHEDT SHA: 92ec5de

See the following load profiles which are very similar. Clg-0pct.csv has zero cooling load in the first month, while Clg-10pct has a relatively small cooling load in the first month. A plot of the first and last day of the year for these loads is shown below.

GHEDT will compute a size for Clg-0pct.csv; however, it will crash for Clg-10pct. Tracing the issue through the code - initially, I found that the natural log of a negative value was attempting to be compted here:

However, continuing to trace back to the origin of the issue, we find that negative first hours for the peak heating and cooling loads are being computed here:

I suspect that this is due to issues related to adding the last day of the year on to the beginning of the simulation for cases when the peak load occurs at the beginning of the simulaiton. Perhaps a workaround is to just make sure that these peak hours never go negative?

GHEDT SHA: 2a1238e

Load Profiles
Clg-0pct.csv
Clg-10pct.csv

@mitchute I realized I kind of like your check better for abs(diff) < tol since the maximum of the month should be in the 48-hour period so that only wouldn't be true when the max is from the first 24 hours that is the last day of the previous month (and would always be larger than the current months max if its the max of the 48-hour).

Originally posted by @j-c-cook in #90 (comment)

Also, I think we may have talked about this day-ahead load picking before - but if not, I just want to make sure you're not doing that for the actual first day of the simulation. We really do not have load history before the beginning of the simulation, so in that case, it doesn't make sense to wrap the end of the year back onto the front of the simulation.

You may have already figured that out, but it was in my mind, so I thought I'd get it out here.

Originally posted by @mitchute in #84 (comment)

Is it possible to automatically select a configuration based on the minimum/maximum temperature after steady-state e.g 25 years?

The nested zoned rectangular search currently requires an exhaustive search once the domain of interest is selected. Depending on the size of the domain, this exhaustive search for a minimum could take longer than what was presented in Cook 2021. A way to overcome the exhaustive search for the minimum is to implement an integer golden section search for the minima.

The goal of this issue is to incorporate adequate testing of ghedt and subsequent packages (PLAT). Implementing tests based on examples in my thesis (Cook 2021) will suffice.

ghedt is utilized in an online website to quantify economic benefits for utilizing ground heat exchangers. This package can utilize a single U-tube, multiple U-tubes or a coaxial tube borehole heat exchangers from pygfunction. The online techno-economic tool uses EnergyPlus for simulating the g-functions. EnergyPlus can only accept input for a single U-tube. Therefore, the equivalent single U-tube will be exported for ORNL.

The thermal property object contains thermal conductivity k and volumetric heat capacity rhoCp instances. The grout variables used throughout the program and examples were previously pointed at the ThermalProperty object. However, a Grout dedicated object that simply inherits from ThermalProperty has now been created. The purpose of this issue is to redefine all grout variables (modules and examples) to point to the Grout object.

The issue is resolved, but I am getting the following runtime warning:

RuntimeWarning: invalid value encountered in log g_values = g(np.log((_time * 3600.) / ts))

This warning has no effect on the determination of a field.

Originally posted by @j-c-cook in #80 (comment)

Adequate testing is important for maintaining the integrity of the repository. Local Github runners (on personal PC's) aren't recommended for use in public repositories due to the security threat they pose. Travis CI/CD claims to have been free since 2011. However, IMO the best option is to setup a machine that has a virtual environment with all three platforms.

MassimoCimmino/pygfunction#180 (comment)

The design interface does not currently allow the user to define the method. Therefore, the default of hybrid is utilized when searching for a field. This did not occur to me until I recommended that the hourly method be used to determine a field while a bug was being fixed. I have always used hourly to validate hybrid and will just setup a ghe and simulate it.

This enhancement is a matter of modifying the API in a few places.

Originally posted by @j-c-cook in #84 (comment)

The design module will utilize the domain.py and the search_routine.py modules. A common design interface will be created.