General questions about the input parameters


#1

Hi all,

I was comparing some of the latest studies using UWG (Aiko Nakano, 2015; Jiachen Mao, 2017; Jiachen Mao, 2018) with the dragonfly plugin and I got a few general questions regarding the inputs required:

1 - As I understood, some of the inputs required by UWG are made as constant and not possible to change in DF, supposedly because they are not as straightforward as the current parameters. According to Nakano’s thesis some of the parameters (e.g. night setpoint end time, maximum discritization lenght for UBL model and minimum wind velocity) are significant, but those parameters are not shown or editable in DF. Is there any way to see what values are being used for those and perhaps edit them?

2 - The “DF CIty from Parameters” is quite useful for generic studies, but there are several parameters that I couldn’t edit when compared to the “DF City” component (e.g. floor height, fraction of waste into canyon, roof vegetation). Many of those are also considered significant according to Nakano’s studies. Is there any way to incorporate those parameters using the “City from Parameters” option?

3 - In UWG, the building systems are very detailed, including materials (U-Value), infiltration, internal gains and chiller COP. In DF, I believe those parameters are carried by the “Building Program” and “Building Age”. Some of the building parameters, such as glazing ratio and albedo can be edited with the “DF Edit Typology Envelope”, but others, like the ones I cited above I could not change. Is there any way to see/ edit those parameters via grasshopper, as some of those are quite interesting to study and can have a significant impact on UHI?

4 - How does the tool differentiate between grass and trees in its calculations? Are the vegetation parameters component related to both, or one of them specifically?

5 - Since UWG runs a building energy model for its calculation in a iterative way, is it possible to extract the results for estimated energy consumption of buildings in UWG or that requires to run a separate model using the urban weather (output from UWG)?

Sorry for the large number of questions and thank you for the assistance :slight_smile:

Regards,
Luis


#2

@lguilhermers, sorry for the late response.

Here’s some initial anwers:

1 - As I understood, some of the inputs required by UWG are made as constant and not possible to change in DF, supposedly because they are not as straightforward as the current parameters. According to Nakano’s thesis some of the parameters ( e.g. night setpoint end time, maximum discritization lenght for UBL model and minimum wind velocity ) are significant, but those parameters are not shown or editable in DF. Is there any way to see what values are being used for those and perhaps edit them?

2 - The “DF CIty from Parameters” is quite useful for generic studies, but there are several parameters that I couldn’t edit when compared to the “DF City” component ( e.g. floor height, fraction of waste into canyon, roof vegetation ). Many of those are also considered significant according to Nakano’s studies. Is there any way to incorporate those parameters using the “City from Parameters” option?

For this level of customization, I would recommend you go directly to the python code itself, rather then rely on Grasshopper. No matter how much we expose parameters in the the GH components, the python code will always be the ultimate source of truth and give you the most flexibility. The good news is that thanks to @AntoineDao, the latest version of the UWG is now available as a package on PyPI. So if you know python (or are willing to learn) you can install it with: pip install uwg, and then test everything you want.

3 - In UWG, the building systems are very detailed, including materials (U-Value), infiltration, internal gains and chiller COP . In DF, I believe those parameters are carried by the “Building Program” and “Building Age”. Some of the building parameters, such as glazing ratio and albedo can be edited with the “DF Edit Typology Envelope”, but others, like the ones I cited above I could not change. Is there any way to see/ edit those parameters via grasshopper, as some of those are quite interesting to study and can have a significant impact on UHI?

@chris can speak more to this. Not sure about the timing and specific inputs but last we discussed the plan was to expose more building parameters.

4 - How does the tool differentiate between grass and trees in its calculations? Are the vegetation parameters component related to both, or one of them specifically?

Good question. I’ll have to get back to you on this, as as I recall it’s done in a somewhat counter-intuitive way.
In the meantime, if you want to have a better idea of the model components, I would advise checking out the UWG’s original author’s work on the model: https://dspace.mit.edu/handle/1721.1/77774 .

5 - Since UWG runs a building energy model for its calculation in a iterative way, is it possible to extract the results for estimated energy consumption of buildings in UWG or that requires to run a separate model using the urban weather (output from UWG)?

Yes, this one is on my todo list. The original tool outputs a heat balance of not only the building energy, but also the energy in the canyon, and therefore is something really useful to have. That being said, @chris is working on a method to obtain city energy results, that will be much more accurate then what the UWG provides, so I recommend using that when it’s available for city energy purposes.

-S


#3

@lguilhermers ,
Here are my thoughts:

1 | 3 - For parameters that are not currently exposed on Dragonfly, you have three options. The first (which I would recommend you start with) is just to add any extra parameters that you want to change to this part of the code in the “Run Urban Weather Generator” component. You can see that the code in that component is really just setting parameters of a uwg object based on the Dragonfly properties and so there’s nothing stopping you from just setting more properties of the uwg object yourself. You can see what some of the other uwg parameters are called by browsing through the code of the UWG that sets up the simulation.

If you get good at this, you might just be able to set up your own runs of the UWG without needing dragonfly at all, using the PyPi package that @SaeranVasanthakumar mentioned (this PyPi method is your second option).

Lastly, as @SaeranVasanthakumar mentioned, we plan to expose more parameters related to building properties on the dragonfly[+] library. Essentially, anything that you could assign to a honeybee zone will be assignable to the Dragonfly objects (including envelope materials, schedules, and loads). If you are willing to wait a few months, you should see many more of these properties becoming available.

2 - This is something that you can do pretty easily right now by looping through the typologies on the DF_city object before outputting it from the component like so:
for typol in DF_city.typologies:
typol.fract_heat_to_canyon = 0.2

5 - As @SaeranVasanthakumar says, the UWG is an energy balance calculation and so there is a number for building energy use under the hood. However, the UWG makes certain assumptions that are fine when you are only concerned about modeling average temperatures across the urban canyons of an district but are typically not ok when you are trying to estimate the energy use or peak load of buildings. Perhaps most critically is the fact that the UWG does not account for the orientation of buildings since it models a single infinite, omni-directional urban canyon. Again this assumption is ok when we are only trying to understand the air temperature change in an average urban canyon but it will not model peak solar conditions correctly for buildings and the fact that the UWG is unaware of whether glazing is on the south/north of buildings vs east/west gives me a hunch that we could get UWG energy use results that are far from those of an E+ run. Perhaps when we get Dragonfly[+] to align the inputs between UWG and energy simulations (Dragonfly[+] will eventually support urban energy simulations with E+/OpenStudio), we can do a validation study to see if this hunch is correct.