Clarification on Heat Injection/Rejection Calculation for Thermal Network in Geothermal boreholes sizing with Dragonfly

Batiste · May 1, 2024, 6:42pm

Hi @chris , I’m unsure about the process the Thermal Network uses in the Dragonfly routine for sizing geothermal wells. Specifically, I’m questioning whether it directly uses the aggregated thermal demand from all buildings as heat injection/rejection to size the wells, or if it considers the efficiency of heat pumps (with cooling efficiency of 3.5 and heating efficiency of 2.5 as determined in the system_params) to convert this thermal demand into the heat rejection or injection from these pumps into the ground. Could you clarify how this conversion from thermal demand to heat injection/rejection as imput for Thermal Network is handled in the simulation?

Thank you so much

chris · May 30, 2024, 4:45pm

Hi @Batiste ,

This is a very good question and, while I’m sorry that I didn’t answer it sooner, my knowledge about this topic is a lot better than it was 2 weeks ago. So I can give you a better answer now, though I might still need Matt Mitchel’s help to answer it fully (he is the author and maintainer of the ThermalNetwork package).

First, I can say that the way that the ThermalNetwork package auto-sizes the GHE is with the GHEDesigner Python package, which has pretty good documentation, which you can find here:
https://ghedesigner.readthedocs.io/en/latest/

Under the “Loads Schema” section of the docs, I can see that Matt put a placeholder for the loads from the heat pumps but this field is currently unused:

So I would assume that one has to do some manual work to process the building loads into ground loads, which would involve adding/subtracting out the heat pump loads. I don’t see “cooling efficiency of 3.5” or “heating efficiency of 2.5” in the system_params.json schema that we are passing to URBANopt CLI (let me know if I am missing something).

I know that Matt has referred to this whole workflow as WIP and he recently got a good chunk of funding to refactor and update the GHEDesigner package starting in September of this year. I’m hopeful that he’ll add full support for heat pump loads with this funding.

All of this means that it’s very possible that all of the heat pump’s affect on the ground sizing is ignored at the moment and is just slated for “future work” until September.

I’m going to reach out to Matt for clarification but one way that you can test this for yourself is with a new component that I just added to Dragonfly, which interacts directly with GHEDesigner to size a GHE given site geometry and a timeseries data collection of ground loads. I just added a dragonfly sample for this here, which takes the G-function from the GHE sizing and uses it in an Ironbug simulation of a single building with WSHPs. You can see the GHE sizing calculation in the middle of the sample file:

In that file, you will also see a section where I take the building thermal loads from an initial E+ simulation and I try to convert them into ground loads to be used in the GHE sizing simulation (accounting for heat pump COPs):

So you could do a comparison between the GHE sizing information that you get from URBANopt vs. the sizing info you get by directly interacting with GEHDesigner using building loads that you’ve edited to account for HP COPs. If the results are significantly different, then it is possible that the URBANopt workflow does not yet account for HP COPs and you might have to do some manual editing to account for the COPs in the workflow.

Batiste · June 1, 2024, 6:50am

Hi @chris,

Thank you so much for your reply. I have seen the simulation screen when DF Run Modelica DES is executed, and it appears that the COP applied is 3

Regarding your sample, I was not able to run it. When I run the simulation, there are not cooling or heating loads, but the main problem is that the new District Thermal components have problems during initialisation.

It seems that the new components library is not loaded, even though I download Ladybug tools from Pollination again.

chris · June 1, 2024, 3:53pm

Thanks for the info, @Batiste .

I hadn’t been reading all of the stdout from the ThermalNetwork package and you are right that it lists a COP there. Given this, it seems likely that GHEDesigner does not yet have native capabilities to account for the heat pump COP but the ThermalNetwork package is doing something to account for it before it passes the ground loads to GHEDesigner.

I’ll ask Matt to see if I can get you a concrete response. Because all of the packages are open source and on GitHub, I guess we could also just dig through the code and see what is happening if all else fails.

As for this:

You are experiencing a bug in our core libraries that I just fixed on Wednesday of this past week. I think the fix might not have made it into a Pollination installer yet so, to get the sample file to work for you, you’ll need to run the LB Versioner component and restart Rhino. After that, you should get the hot and chilled water loads coming in from the initial simulation of building loads. That should also get the rest of the new components to work and enable you to run the rest of the sample file.

Batiste · June 2, 2024, 7:35pm

I’ve tried to read the documentation of Thermal Network and it seems that they always work with ground loads. Additionally, they have developed a module to manage the conversion from thermal loads to ground loads. The issue now is being able to change the COP for dimensioning.

I’ve tried the sample and it works perfectly. I connected my district loads and the dimensioning is almost the same for a COP of 3, but now I am struggling to change the geometry of the site. I am not able to reproduce the same type of element (trimmed surface) to get the dimensioning working with another geometry.

Regarding the simulations in OpenModelica, I take this opportunity to inform you that we have managed to simulate 8-9 buildings (although we have to manually adjust the distribution pump pressure, manually include the maximum cooling and heating loads in the heat exchangers of each building, and also handle buildings without HVAC or with only cooling or only heating very carefully).

To conclude, the new district thermal module is amazing!

chris · June 4, 2024, 12:24am

Thanks, @Batiste .

I passed your question about how to change the COP along to Matt and we’ll see what he says. If there’s no clear support for this at the moment or it takes him a while to get back to us, I know that there should always be a way to do it by just editing the source code of the ThermalNetwork package. Let’s give him some time to respond but I’m sure I can probably find the place in the source code where the current COP of 3 is specified.

And this is wonderful to hear!

Would you mind if I quoted you on this? I think you may have taken the DES workflow the farthest out of anyone I have seen on this forum and a statement like this might be really helpful as NREL continues to apply for grants to fund the DES work.

Batiste · June 4, 2024, 7:42am

Of course, no problem. Even if I can get in touch with someone who is developing the GeoJSON to Modelica part or the Modelica Building Library, I could share my errors with them to see if it could be useful. However, it is quite difficult to reach them. I don’t expect them to be as active as you are, but something in between would be nice. Thank you very much, Chris.

mitchute · June 5, 2024, 2:04am

Hi @chris and @Batiste! Sorry for the delay in responding to this. Feel free to bother me here or at my work email if you don’t get a quick reply.

GHEDesigner is currently limited to requiring the ground loads, but as was mentioned, we’re going to be updating it to be able to handle accepting the building loads which will account for variable heat pump performance. We’ll also be adding a bunch of other new features which should make some of these things easier. For now, TN hard codes the cooling and heat pump COP values, and uses that to convert building loads to ground loads.

Also, my apologies for the poor documentation on ThermalNetwork. Nate as a PR stubbed out, but it’s stuck with me needing to wrap it up. I’m excited to see the progress you have made! Let me know if I have missed anything else in the thread above.

chris · June 5, 2024, 2:24pm

Thank you, @mitchute .

Really great to see you on the forum! And thank you for the response.

That’s good to know that exposing the COPs in an official way is on the roadmap. Just to give a workaround in case @Batiste really needs to change the COP for the GHE sizing calculation right now, it seems like this is the line of code where the ThermalNetwork package is setting the COPs of 3:

github.com

NREL/ThermalNetwork/blob/b32d155359029950ad9fd7fb83221986b6cd21c7/thermalnetwork/network.py#L273


      
          obj = {
              "id": "",
              "name": "simple fan",
              "type": "FAN",
              "properties": {"design_flow_rate": 0.25, "design_head": 0, "motor_efficiency": 0.6},
          }
          obj["name"] = str(obj["name"]).strip().upper()
          self.components_data.append(obj)
          
          # Add WAHP
          obj = {"id": "", "name": "small wahp", "type": "HEATPUMP", "properties": {"cop_c": 3.0, "cop_h": 3.0}}
          obj["name"] = str(obj["name"]).strip().upper()
          self.components_data.append(obj)
          
          for comp in comp_data_list:
              if self.check_for_existing_component(comp["name"], comp["type"], throw) != 0:
                  return 1
              comp["name"] = str(comp["name"]).strip().upper()
              self.components_data.append(comp)
          return 0

It seems like the cop_h (for heating) and the cop_c (for cooling) get fed directly into the module that tries to account for the heat pump:

github.com

NREL/ThermalNetwork/blob/b32d155359029950ad9fd7fb83221986b6cd21c7/thermalnetwork/heat_pump.py#L5-L10


      
          class HeatPump(BaseComponent):
              def __init__(self, data: dict) -> None:
                  super().__init__(data["name"], ComponentType.HEATPUMP)
                  props = data["properties"]
                  self.cop_c = props["cop_c"]
                  self.cop_h = props["cop_h"]

So, if I’m right that this is the only place in the package where the COP of 3 is being set, then all that @batiste would have to do in order to change the COP for all simulations run with the ThermalNetwork package is edit the line in this file on where you # Add WAHP:

C:\Program Files\ladybug_tools\python\Lib\site-packages\thermalnetwork\network.py

In the version of ThermalNetwork that Dragonfly is currently using, it looks like this is on line 251:

After saving the file, @batiste, the next time that you use the DF Run Modelica DES component, it will size your GHE using the newly-specified COPs.

Let me know if I have gotten anything wrong, @mitchute , or if you get the chance to test it out, @Batiste .

I’m really looking forward to all of the improvements that you and Nate have coming down the pike, @mitchute . We’ll have to revisit this after the big update that is planned to GHEDesigner.

mitchute · June 5, 2024, 2:38pm

Thanks, @chris. Yes, that all looks right. I will also just note for reinforcement that the COP values referred to here are only used for GHE sizing. Once the Modelica models are generated, you will have heat pump models with variable performance, which should hopefully give you a better sense of the “true” performance.

Batiste · June 6, 2024, 5:33pm

Thank you @mitchute and @chris for the responses and the detailed information.

@mitchute, it’s great to know that exposing the COP values officially is on the roadmap. I’m excited about the upcoming features.

@chris , thanks for the temporary workaround. I have tried the modification in the network.py file to adjust the COP values according to your instructions, and it works perfectly. I also noticed that in the latest update, the Effective Borehole Resistance has improved to approximately 0.0977, whereas the same simulation previously gave 0.115. This means that with the new update, the requirement for boreholes and meters of drilling is reduced, but I am not able to reproduce the previous behavor or undestanding what is new.

However, I’m currently having issues with Modelica ( probally not realated with GHEDesigner neither Dragonfly) not accounting for the cooling loads, or the simulation gets stuck at 99% with many warning messages, some of them related with low temperarures in the buildings in heating mode:

I have created an issue in the following forum. @chris Do you think it makes sense to open a thread in this Ladybug/dragonfly forum as well?

I really appreciate your help and the information you’ve shared.

mitchute · June 6, 2024, 8:34pm

@Batiste thanks for flagging that. I misunderstood that those were not already being forwarded through. We’ll at least get that part fixed ASAP.

Also, the GHE sizing code should be generating some output files. If you do track those down from the previous and current simulations, please send them to me and I can help track down what happened wrt borehole resistance.

Batiste · June 7, 2024, 1:58pm

I’m sending you the previous version and the current version with the output files from the sizing process. Thany you so much
ghe.zip (321.4 KB)

chris · June 10, 2024, 3:07pm

I’m very happy to see this discussion and thanks for providing the files, @Batiste. Hopefully, Matt gets the chance to take a look at them soon but, if this ends up being something that takes a while to address, we could also just put this all into an issue on the GHEDeigner GitHub so that it doesn’t get lost.

And, speaking of where to open certain GitHub issues,

I see that Michael Wetter already instructed you to post the issue on the geojson-modelica-tranaltor (GMT) GitHub rather than the Modelica Buildings Library (MBL) GitHub. I would agree with him that this is the right place for that issue and, generally speaking, I might recommend opening issues first on the GMT GitHub before moving to the “lower level” of code where the MBL is.

Someone like Nate Moore or Nick Long can probably diagnose what is going on, particularly if you give them good minimal sample files so that they can recreate the issue. I know that there are a number of challenges that the GMT is still working through with regards to producing Modelica files that reliably simulate without issues. This is particularly so because the GMT has the goal of fully-supporting OpenModelica, which is currently under heavy development. All of this is to say that you may be able to work around some of these exceptions that you get from OpenModelica if you have access to Dymola. But I also know Dymola is expensive (we couldn’t justify buying a license given the small company that Ladybug Tools LLC is).

Lastly, to answer the question about whether or not a separate topic should be opened here on the Ladybug Tools forum, I don’t think we need to right now. The types of questions you’re asking here really require the expertise of the people at NREL and, at the moment, @mitchute 's the only person from NREL who I know has an active profile on this forum. So we can stick to the NREL GitHub repos for issues that arise on this level.

Along those lines, thanks again, Matt, for joining this forum. As you can see, it means a lot to many of us that you’re here and I hope that you’re able to get the sense that I have from these discussions that people are using your work in very cool ways.

mitchute · June 11, 2024, 4:39pm

@Batiste I took a very cursory look at your files. The borehole resistance did change slightly, but not enough to justify the large change in GHE design. I haven’t yet tracked the source of that change. Similarly, the loads also did change somewhat, but again in my opinion not enough to justify the large GHE design change. If you can think of other things that might have shifted between the runs, feel free to let me know. I won’t have more time to dissect this for several weeks, but I’ll see if I can track down the culprit when I return.