URBANopt and HVAC system

Hi, I’m Junoh and I want to model urban-scale of energy demand.
But when I tried to change HVAC system to heat/cool system with residential AC with baseboard gas boiler, my system used district heat. How can I change the heat source for URBANopt and dragonfly? Could anyone answer me??

Thanks, Junoh

from_building_footprints_modified.gh (125.6 KB)

Hi @Junoh ,

Something seems to be corrupted about the Grasshopper file that you uploaded:

Also, your screenshot shows that you are not assigning the residential system.
This is how you can assign it to all of your Dragonfly Buildings:


from_building_footprints_residential_AC.gh (60.4 KB)

The resulting OSM/IDF files will all have residential AC and Gas Boilers in this case.

Hello @chris, thank you so much for the reply!!
However, when I ran gh file that you uploaded with URBANopt components, district heating appeared again. I think URBANopt default setting keeps selecting district heating as a heating source. If you know how to adjust measures/mappers to change heating source, please let me know.
Thank you again for the kind reply!!


from_building_footprints_residential_AC.gh (85.0 KB)

@Junoh

That District Heating [GJ] value is actually for the service hot water (SHW) that’s serving the model. The space heating is showing up under the Heating row and Natural Gas [GJ] column.

I know you would expect the service hot water energy to show up under the Water Systems row but we are currently unable to do this because of limitations in OpenStudio and EnergyPlus.

In the future, we’ll add detailed service hot water systems into Dragonfly and Honeybee, and the energy use of these detailed systems will show up in the Water Systems row of that table. These future SHW systems will also allow you to get the electricity/fuel used for service hot water (instead of just getting the SHW load as district heating).

@chris
Thank you for your kind reply.
In fact, I was trying to model SHW system run by gas boiler too :sweat_smile:
Since replacing SHW system is not available, I want to know how much energy is consumed for the hot water system if I replace it to gas boiler.
I mean, district heating energy demand shown at that table is primary energy? If not, could I assume it as a general district heating?

Hi @Junoh ,

You can think of the current SHW district heating similar to how you would think if ideal air loads compared to a detailed HVAC. In other words, the SHW district heating is the amount of heat that needs to be transferred to the water coming through the water mains in order to meet the SHW demand in the Rooms (aka. the SHW load or SHW demand).

You can see the plan for the detailed SHW systems that I will add here:

The “tankless” (aka. on-demand) system templates that I listed there are essentially going to use a Boiler object to supply the heat to the SHW loop and so they’ll be able to account for the efficiency of this boiler/burner. The other two templates will use the E+ WaterHeater object, which includes a tank and will model the losses from that tank in addition to the burner efficiency.

For the time being, if you want to get a sense of the fuel energy that a SHW boiler would need, you can just divide the current SHW district heating by the efficiency of your boiler and that will give you essentially the same thing that the tankless system templates will eventually give you.

Hello @chris , when checking the osm file formed by URBANopt I found the surfaces between adjacent stories are not combined and both ceilings and floors have been set to be adiabatic. Is this phenomenon normal and can we modify it?

Hi @Jay ,

That is how the Dragonfly plugin has been structured so that each story is a simulate-able unit.

How are you creating your model? Is it from building footprints so that each room is the same as the one below it? If so, you can use the DF Model To Honeybee to translate the Dragonfly model to Honeybee and then solve adjacency between all of the resulting Rooms using the HB Solve Adjacency component. Then use the HB Model To OSM component to run the simulation.

Using methods like that, I haven’t been able to get more than a 1% difference in energy use between the adiabatic floor/ceilings and those with a Surface boundary condition. However, if you are modeling a passive building where the temperature between the stories can vary a lot, I would understand why you would want to use Surface boundary conditions instead of adiabatic ones. Are you trying to model passive buildings in your case?

Thank you for your confirmation @chris . I’m analyzing the energy consumption of rooms at different height. And to rooms near the ground or at the top level, the 2 surface boundary settings will lead to big difference. Actually I’m facing a dilemma, running URBANopt can solve a lot of time and running Openstudio can lead to more accurate results but not efficient. Is there a perfect solution? (Especially, separate the buildings in Openstudio model into target building and shadings, just as what URBANopt does) Thank you very much.

You can usually simulate things more efficiently than URBANopt by using the “Model To OSM” component alongside the HB Run OSW component. Just export each Building in the Dragonfly Model to a Honeybee model, solve adjacency within each building, connect up the list of Honeybee Models to the “Model To OSM” but have it only write_ the OSW, then connect the list of OSWs to “HB Run OSW.”

The from_building_solids.gh sample file that comes with the Food4Rhino installer should give you a sample of this workflow (without the solve adjacency step). Long story short, there’s no need to use the URBANopt workflow purely for efficiency. You’ll need it if you need to do postprocessing with REopt, OpenDSS, etc. But you don’t need it if you just want to run each Building in parallel.

1 Like

Thank you for your suggestion. Now I have made a not perfect but good enough workflow. :grinning:

FYI, @Jay , after thinking about this more, I think we’ll add an option on both DF Model to geoJSON and the DF Model to Honeybee components that automatically solves adjacency between relevant ceilings/floors upon export. It will only use Surface boundary conditions in the case that the roofs and floors of rooms match each other but this sounds like it will allow you to get the models that you want in the URBANopt workflows.

I opened an issue about it and you can check there to see progress on whether we have implemented it: