Adding Dynamic Load Aggregation Scheme - #81
Conversation
|
Thanks, @ishraque2008. Please add a basic description of the work to the "Pull request overview" above. We also will need a unit test to exercise the new code. I'll also likely provide some comments related to portions of the code soon. |
|
@ishraque2008 thanks for adding the description in the pull request overview, and for cleaning up some of the code. There are two things I would like to see here before this gets merged.
As I see it currently, the required timestep input field has not been forwarded on through the code, as is noted in the schema here. This would need to happen before anyone can use this new feature. As it stands now, this code is likely unreachable. |
Added Test and Demo scripts, updating parameters in Demo file to align with latest version.
|
@ishraque2008 thanks for picking this back up again! If you'd rather not wait for GitHub to run the tests, which takes 10+ minutes, you can run them locally. After pip installing the requirements ( You can also add the E.g. Depending on your setup there may be a few other tricks that are needed, so if you run into any issues with that let me know and I can help. |
…resolve associated test failures.
@mitchute Sorry about the long delay to pick up. I'll make sure to be more prompt from now on. |
| from ghedesigner.utilities import eskilson_log_times | ||
|
|
||
|
|
||
| class TestLoadAggregation(GHEBaseTest): |
There was a problem hiding this comment.
It would be much preferred if you could update this test to follow this example.
GHEDesigner/ghedesigner/tests/test_find_design_rectangle.py
Lines 6 to 26 in e055caa
The previous tests were quite verbose. The new approach is a much more compact way to do the same thing.
There was a problem hiding this comment.
Thanks! I fused the two concepts and made the test even more concise.
| continue_if_design_unmet=continue_if_design_unmet | ||
| ) | ||
|
|
||
| timestep = sim_props.get("timestep", "HYBRID").upper() |
There was a problem hiding this comment.
Nice touch. I was not aware of this dict function.
|
From the PR description, above
It would be fantastic if you could give a few statistics, plots of differences in simulation times and design outputs, or something else to help see what improvements this may or may not offer. |
@mitchute Thanks for your inputs. Let me address all the suggestions. |
… alongside 'HYBRID', allowing for more flexible simulation configurations
@mitchute Done. Please let me know if more statistics are required. |
Hello @mitchute I just added some more data to the description. |
|
Alright, I think I have done as much as I can at this point. I'm going to need to kick it back to you (@ishraque2008) for some further investigation. To get here, I have cleaned up the code so we are not passing in duplicated, unnecessary arguments. I have also added another member to the enum for tracking which timestep method is being used, then updated the logic to switch on those enum values instead of the strings that were being passed around. I'm fairly confident all the right code is being hit now once the proper flag is actuated. To my knowledge, I didn't touch any of the new load aggregation code. However, I think there are still some issues here that warrant further investigation. I looked at the following schemes and sizing periods: Hybrid (20 yr), Hourly with LA (20 yr), Hourly w/o LA (1-8, 10, and 20 yr). See the plots below. (the cases are labeled by the number of months in the sizing period) In the first plot, we see the GHE ExFT for the Hybrid, Hourly with and w/o LA for 20 years. Over the sizing period, the hourly with LA consistently underpredicts the fluid temp when compared to the straight hourly simulation. In my opinion, this leads to the results of the second plot.
In this plot, we see the total drilling and simulation runtime for the cases noted above. I was expecting the 20-year cases (Hybrid, Hourly w LA, and Hourly w/o LA) to be consistent. However, the case with load aggregation yields a design that is roughly 11% smaller than the other two cases, which in my opinion warrants further investigation.
I also found it strange that the design jumps by roughly 2X when changing the sizing period from 10-20 years, but perhaps this is expected given the loads we're using. @jeffreyspitler, feel free to comment on that point if you think something looks off. My notebook is attached, so let me know if I missed something. Otherwise, I think you might double-check that your LA algorithm is working as expected. |
It appears there's an unexpected behavior with the method. Right after finals week, I'll investigate further to understand and fix the issue. Thank you @mitchute for putting hard work into investigation and code clean-ups. Implementing the method in the enum is the best choice in my opinion. I did this on my initial commit, as its use is straightforward. And about the 2X jump, I'm uncertain if similar trends are evident in other highly imbalanced load profiles too. Here for the Atlanta Office building, the annual cooling-to-heating load ratio is around 23. |
|
Closing this for now. Feel free to reopen it if you decide to pick it back up. |
|
Hi @mitchute , thanks again for your earlier review and for pointing out the discrepancy in the hourly load aggregation results. I picked this back up and reworked the implementation, updated the tests/demo path, and adding new figures and comparison data. As it appears, I have reproduced the "Balanced" and "Imbalanced" loads as described by your thesis, and it seems the results are very close with the Non-aggregated method for a 20 years of simulation. For balanced load the comparison looks like having error below 0.1°C. And for imbalanced load it is also good, less than 0.1° C error. However, whenever we take extremely imbalanced load or the "real" building loads, this is not that perfect. For example, for Atlanta office building load (annual cooling-to-heating load ratio is around 23.), it shows error just below 1°C. However, the real picture comparison can be tested with the hybrid load, that shows error above 3°C (Green lines). So the load aggregation is performing better than it acually was. 
But this is not true for all "real" loads, for example for Chicago Office building, the results are a little better than the synthetic loads: 
While looking at the sizing results, there are some interesting observations with Atlanta office building, which was missing during my previous implementation. I will show this after showing some results first. When sizing for a balanced load, the load aggregation method yields borehole heights more consistent with the no-load aggregation method than the hybrid approach does. Balanced load: And it is followed by the imbalanced load too: The Chicago office building also shows better alignment than the hybrid load: However, for Atlanta office building load, the load aggregation method will show very confusing result: 
As you can imagine, this is not because the load aggregation method is not performing as expected, rather because of the other methods that depend on the overall design procedure, including iteration during sizing and also while searching optimized borefield grid. During the field search iterations, both the Hybrid and Hourly without load aggregation methods reached the 18×8 configuration (B = 5.00 m) and, interestingly, both reported an excess temperature of 0.01 °C, making this the apparent near-optimal design point. However, for the same 18×8_B5.00 configuration, the Hourly Load Aggregation method predicted an excess temperature of −0.31°C instead of 0.01°C. Because the search algorithm uses this excess temperature to guide the next iteration, this small deviation caused the subsequent search path to move in a different direction. As a result, the load aggregation workflow proceeded toward 13×6_B7.08 and 15×7_B6.07, ultimately leading to a less optimal design outcome compared with the Hybrid result. That said, as shown in the earlier comparison plots, the load aggregation method still tracks the Hourly no-load-aggregation solution much more closely overall than the Hybrid method in terms of transient temperature prediction. Therefore, the discrepancy here appears to be primarily a search-path sensitivity issue near the convergence threshold, rather than a fundamental issue with the load aggregation temperature prediction itself. My working files are messy, thats why I am not sharing them here, but would be happy to share any files you think would help you evaluate better. I tested the method with 7-8 other building loads too (which were used for the validation of GHEDesigner), and found, while simulation shows close alignment, the sizing may not always give the best result with load aggregation method. Finally, the updated results look much better now: the hourly load aggregation case follows the hourly no-load-aggregation case much more closely, and I am no longer seeing the earlier unexpectedly smaller design result. Sorry again for the long gap on this. I have been in the final stretch of wrapping up my PhD, which pulled me away from revisiting this branch sooner, but I wanted to come back with something substantially improved rather than a partial update. I really appreciate your earlier feedback, and especially your notebook was instrumental in helping me track down where the discrepancy was coming from. While working through this, I also started exploring a few follow-up directions around even faster simulation and surrogate prediction of thermal response behavior, and the preliminary results are quite encouraging. I did not want to overload this PR thread, but I would be happy to share them at your convenience, if you are interested. |
2 participants
Pull request overview
Summary:
This pull request introduces a load aggregation scheme to GHEDesigner, enhancing the efficiency of the hourly simulation process while maintaining accuracy. The proposed methodology is based on Claesson and Javed (2012) [1] and Mitchell and Spitler (2019) [2] papers, allowing for faster simulations without compromising reliability.
PR resolves (GHEDesginer Limitations number 2)
"An hourly simulation is available, but it doesn't make use of load aggregation, so is very slow."
Key Changes:
Load Aggregation Method: Implemented load aggregation technique outlined in source papers to streamline simulation by aggregating loads within intervals.
Faster Hourly Simulation: The new approach significantly reduces computational overhead, enabling faster results while maintaining accuracy.
Improved Design Workflow: Users can now perform hourly simulations while finding borefield design, eliminating the need for separate simulations, first Hybrid and then Hourly. However, finding design in Hybrid is still the fastest, and gives reliable results in my experience.
Enhanced Performance: GHEDesigner's overall performance is improved, making it suitable for larger simulations and complex heat exchange systems.
Expected Benefits:
Reduced Computational Time: Load aggregation should significantly decrease the time required for hourly simulations.
Scalability: GHEDesigner will be able to handle larger and more complex systems with improved performance.
Consistent Results: Despite speed improvements, the methodology ensures reliable results for design and analysis with minimum absolute error.
Comparison between Methods:
This section presents a comprehensive comparison of simulation methods employed in the study. Specifically, the performance of the Hybrid and Load Aggregated Hourly methods is assessed relative to the Hourly simulation, which serves as the standard reference.
A 30-year simulation on Atlanta Office building with 156 boreholes is conducted to evaluate the efficacy of each method in calculating maximum and minimum Hourly Peak Extraction Fluid Temperatures (HPEFTs), alongside the computational efficiency measured in terms of simulation times.
The error is calculated as the difference between hourly simulation and load aggregated hourly simulation. I can be observed for the 30 years of simulation, that stands to have a maximum absolute value of 0.2 °C.
The error profile is similar as the 1 year simulation getting repeated each year for this load, as shown below:
As the hourly load aggregation depends on expansion rate and number of bins at each level, we followed the suggestions from Mitchell and Spitler paper, where they optimized the ideal expansion rate could be 1.62 or the Golden ratio [2].
For the first 48 hours of the 30 years of simulation, the aggregated simulation and hourly simulation predicts almost the same temperature:
And for the last 48 hours of the simulation also gives pretty accurate results:
Upon scrutinizing the maximum and minimum HPEFTs, the Load Aggregation scheme exhibits a maximum absolute error of 0.024°C and 0.004°C, respectively. Notably, these deviations remain within acceptable limits, especially when compared to the Hybrid timestep method. The maximum absolute error for the whole hourly simulation period is 0.2°C.
Regarding simulation time, the Load Aggregation method showcases a remarkable improvement, completing the simulation approximately 106 times faster than the conventional Hourly method. However, it is important to note that the Hybrid timestep method outperforms both, achieving a speed enhancement of 15089 times compared to the Hourly method. This efficiency disparity arises from the Hybrid method's monthly simulation frequency as opposed to the hourly frequency of the other methods, resulting in difference in array sizes. The 30-year hourly simulation required approximately 16 minutes to complete, while the Load Aggregation method accomplished the similar task in just 9 seconds.
It is worth to note that, the higher is the simulation duration, the load aggregation becomes more time saving. For example, when a 150 hours of Hourly simulation takes about 9 hours and 30 minutes, it takes only 34 seconds with load aggregation scheme, saving 99.9% of computational time. However a 1 year of simulation, takes less than a second for both hourly and load aggregation schemes, where the time saved by aggregation is only 67 %. We have compared the simulation time, and Root Mean Square Error (RMSE) for the whole simulation period for a number of simulation duration, and found the following results:
Thus the simulation time expands exponentially with higher simulation duration in such calculations. The computational complexity of determining the heat pump entering fluid temperature can be expressed in big O notation as O(n!), where 'n' represents the number of time steps utilized in the simulation.
The following chart is presented for a better visualization:
For a more detailed comparison with numerical values, please refer to the following table:
Feedback, suggestions, and testing are requested from the development team and community members to ensure the stability and effectiveness of the load aggregation feature.
Thank you for your contributions!
Ishraque Zaman Borshon
References:
[1] Claesson, Johan, and Saqib Javed. "A load-aggregation method to calculate extraction temperatures of borehole heat exchangers." Ashrae Transactions 118, no. 1 (2012): 530-540.
[2] Mitchell, Matt S., and Jeffrey D. Spitler. "Characterization, testing, and optimization of load aggregation methods for ground heat exchanger response-factor models." Science and Technology for the Built Environment 25, no. 8 (2019): 1036-1051.
Checklist