Hi @chris,
Last week I successfully ran the GHE example from the Grasshopper-dragonfly GitHub repository, but today when I downloaded the sample again, I was unable to run the workflow. I have the following error: 1. Solution exception: A part of the path ‘C:\Users\Usuario\simulation\Buffalo_Development_GHE\run\honeybee_scenario\ghe_dir\Hospital GHE Loop_GHE_0\SimulationSummary.json’ cannot be found.
Is it an issue related to changes you have made in the last 5 days or is it my problem?
Thank you.
[Update] The DES example for the 4th generation DES works perfectly, including running the Modelica (Docker image) simulation and obtaining the results. However, the GHE example still encounters the same problem.
Thanks for being on top of testing. And, yea, it took us a few extra weeks to iron out the details of the GHE example but I’m happy to say that it works now.
Just use the LB Versioner to get the latest development version of the plugin and then you can use this sample file to test the GHE. Let me know if you experience any issues and thanks again!
I’m trying to do a test with my network, but I have some issues with putting two ghe sequentiall or staggered as in the examples of the ThermalNetwork repository. I undesrtand that the DF GHE Thermal loop and DF Run ModelToGeojson are not detecting well the thermal connectors between ghe geometries and with multiple ghe geometries. Is it courrently possible to make these types of networks?
Can you provide a sample Grasshopper file for the district and set of loops you are trying to simulate?
NREL has told me that their current packages should support sequential GHE configurations but I have not tested it fully yet. I have written the dragonfly methods in a way that you should be able to supply multiple GHE’s to the district loop:
So, if it’s not looking like it is translated to GeoJSON correctly, that may be a bug on our end. Or it means that you have to make sure all of your polylines for the loop are joined together in Rhino if you have not done that already.
Sure! I have got this error in the DF Run URBANopt with the sequential example: 1. Solution exception:Feature “Ground Heat Exchanger” contains 4 connections to ThermalConnectors and cannot be integrated into a valid loop.
If you can test it on your end and confirm that it runs correctly, I’ll probably just make sure this fix is a part of the LBT 1.8 stable release for anyone installing from this point onward.
I have been reviewing the results from the Thermal Network, and it creates two ghe files for each ghe geometry. However, the results are exactly the same for both geometries. Shouldn’t there be a difference since the geometries are different size? Or does it give the result as the equivalent between the 2 surfaces? In that last case, I don’t understand why 2 files are generated. Also, there is no difference between the simulation with sequential and with staggered. It gives exactly the same result. I don’t know if I’m not understanding how Thermal Network works or if there is another problem.
I send you the ghe results from the staggered example ghe_dir.zip (330.1 KB)
Glad that it is working for you. Interpreting the results for your case is something that is a little bit beyond my current expertise. I’m not sure if the Thermal network package is just making a decision somewhere to split the boreholes evenly between the two fields. This may be a setting that you can tweak that I just have not noticed yet.
The person who would definitely know is Matt Mitchell from NREL. I’m going to ping him to see if he might be able to to respond here. You can probably also reach him by opening up issues on the Thermal network GitHub repo.
Let me see if he can respond here first. If this ends up just being a setting that I forgot to expose on the components, I’ll gladly add them when I get the chance.
Thanks again, @chris . I’ll be waiting for further updates. Really appreciate your help and looking forward to any insights from Matt Mitchell or the adjustments you might add.
Nate at NREL is also working on the ThermalNetwork package and told me that he thinks you’re using it correctly and that the package is set up to just distribute the boreholes evenly across the GHEs right now. It sounds like the ability to change this distribution is on their feature development roadmap.
So this might just be a limitation of what is currently exposed. You may be able to customize some things if you’re willing to delve into the ThermalNetwork source code. But, otherwise, perhaps we just wait for the next ThermalNetwork release.
I’ll keep you posted if I find any information to the contrary.
Thanl you so much @chris I think that I will wait for the next ThermalNetwork release as I plan to subdivide my network into different subnetworks, each with one GHE that can work independently.
On the other hand, I have some doubts about converting the GHE block to system_params, about the temperature setpoints that are ultimately exported to Modelica, and also about the possibility of having a water-to-water heat pump in the ETS not only for active heating and hot water but also for active cooling. It seems that when exporting to Modelica, there is a heat pump with a COP of 4 for SHW and a COP of 2.3 for Heating, and for Cooling it does a kind of free cooling at 18 degrees supply temperature. I’ll put it in the following post: GHE system_params
