GHE system_params

Batiste · March 26, 2024, 8:27pm

Hi all, with the GHE_example to simulate District Energy Systems, I do not fully understand the following. It is supposed that when a GHE is connected to the DF Model to GeoJSON, it should create a system_params with fifth-generation properties according to the dragonfly_energy documentation: def to_des_param_dict(self, buildings, tolerance=0.01): “”"Get the DES System Parameter dictionary for the ThermalLoop.

However, in the example, when the DF Model to GeoJSON block is launched, a system_params is created with a configuration like that of the fourthGenThermalLoop, with the following values.

Yet, when the simulation is launched and the Modelica file is obtained, everything works fine. The only issue is that the values indicated in the system_params do not fully match with the values of the ETS or the heat pump in open Modelica.

I do not fully understand how the Modelica file is formed or, for example, if changing the loop from OnePipe to TwoPipe, it no longer simulates anything. But I would like to understand if the system_param is being created correctly and if there is any way to modify it so that when it is a 5g, the heat pump placed in each house is for both DHW and Heating as well as Cooling. Since currently, it only has COP for DHW and Cooling, which I do not fully understand where it is defined in the JSONs, and for cooling, it seems to do free-cooling with a supply temperature of 18 degrees.

As can be seen in the following image, the energy consumption of the heat pump is in green, and the energy delivered by the heat pump to the network both in winter (blue) and in summer (red) of one of the buildings over an annual period. In summer, there is no consumption by the heat pump, and the green line drops to 0.

Thank you very much for your response.

chris · March 27, 2024, 4:30pm

Hi @Batiste

I’ll try my best to answer the parts that I know about but you are starting to get to the point where your questions are better answered by the URBANopt docs. If you’re trying to be at the bleeding edge of this stuff, you should also check the GitHub repo for the geojson-modelica-translator (aka. the GMT).

The GMT is the Python package that NREL has developed to take the GeoJSON and system parameters JSON and then produce the Modelica files that represent the DES using the Modelica Buildings Library. So hopefully that clarifies what exactly is happening when you translate the DES to Modelica.

To go through more of your specific questions:

Yes, that is correct. The system_parameters JSON is needed as input for the GMT in order to describe certain characteristics of the DES. So, whenever you connect a des_loop_ to the component that writes the GeoSON, that method that you referenced there will be used to write a system parameters JSON for the DES. In the case of the 5th generation system with a GHE, this system parameters JSON is also updated with sizing information of the GHE after we get this info from the ThermalNetwork package.

It think you are looking at the wrong part of the dragonfly source code. This is the part of the code that is generating the system_parameter.json for the 5th gen system:

github.com

ladybug-tools/dragonfly-energy/blob/master/dragonfly_energy/des/loop.py#L642-L714


      
          def to_des_param_dict(self, buildings, tolerance=0.01):
              """Get the DES System Parameter dictionary for the ThermalLoop.
          
              Args:
                  buildings: An array of Dragonfly Building objects that are along
                      the GHEThermalLoop. Buildings that do not have their footprint
                      touching the loop's ThermalConnectors are automatically excluded
                      in the result.
                  tolerance: The minimum difference between the coordinate values of two
                      geometries at which they are considered co-located. (Default: 0.01,
                      suitable for objects in meters).
              """
              # set up a dictionary to be updated with the params
              des_dict = {}
          
              # add the relevant buildings to the DES parameter dictionary
              footprint_2d, bldg_ids = GHEThermalLoop._building_footprints(
                  buildings, tolerance)
              rel_bldg_ids = set()
              junctions, _ = self.junctions(tolerance)

This file has been truncated. show original

This part I don’t know but maybe the docs for the GMT on the GitHub repo or the URBANopt docs could help you figure it out. There’s also probably a way to integrate the DES with the Service Hot Water, which the docs may be able to help you with.

The chart of the thermal loads and the electricity of the heat pump is pretty cool. Am I correct that is is coming directly from the Modelica results of your simulation?

Batiste · March 28, 2024, 1:28pm

Thank you so much for your detailed response.

I have been going through the GMT documentation, but I think I need more time to understand how it works.

However, the issue arises when I simulate the GHE example after converting the DF Model to GeoJSON. The system_params are as described in the Dragonfly Energy documentation regarding the 5th generation district. But, once you execute the DF Run DES, the system_params are transformed, with ets_indirect_parameters instead of the fifth generation.

The parameters defined in the system_params for the fifth generation seem to be for a heat pump used for heating, cooling, and SHW, but it appears that this component has not been developed in the Modelica Building Library (MBL) and in the GMT. And the model that it translates to Modelica is a heat pump for heating and SHW and a direct compressor-free cooling system. So, I’m not sure if I should be addressing people involved in the GMT project or the MBL project.

Yes, the graph is from the annual simulation. It is clear that for this type of network, the temperature of the loop, prosumers, and borehole are quite important. Additionally, the energy transfer between the buildings and boreholes to the network is crucial. Regarding energy consumption, it’s evident that the distribution pump and the heat pumps are key components to compare with other network typologies.

chris · March 28, 2024, 2:21pm

Thanks for clarifying, @Batiste . I’ll admit that I don’t know which party we are waiting on here:

… but I will say that the GMT authors at NREL probably have the clearer picture of the whole system given that they need to know things about the MBL in order to write the GMT. So I might start by asking them via an issue on the GMT GitHub (searching to make sure there is not already an open issue about this or opening a new one if you don’t find anything). If it is an issue on the MBL side, then the GMT authors could probably tell you what they need to be implemented in the MBL in order to expose this on the GMT.

And that’s good to know that you made that visualization from the Modelica results. I’ll keep this in mind when I eventually get around to implementing some result-parsing for the Modelica results into Grasshopper.

Batiste · March 28, 2024, 3:28pm

I believe Nathan Moore has pointed this out in the following issue: Enable CLI to automatically build 5G systems that aren't GHE · Issue #621 · urbanopt/geojson-modelica-translator · GitHub. I will attempt to present my question there.

chris · March 28, 2024, 5:33pm

Sounds good. Nate is one of the main developers of the GMT and he’s been my point of contact for a lot of questions that I have had. So, hopefully, he can give some insight to your question if you post there.