General questions about the input parameters

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

1 Like

@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: Study and prediction of the energy interactions between buildings and the urban climate .

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

@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.

1 Like

@SaeranVasanthakumar and @chris,

Thanks so much for the complete replies. It not only gave me an idea how to work with the source codes, but also how the software is structured in general. Looking forward for the future upgrades and congratulations for the good work with the tool.

One quick question that I had looking at the components was that I noticed some components were changed from the Matlab version. For example, I could not find fields for COP, U-Values and Green Walls for example. Did I miss those or they are incorporated in a different way or in a different part of the code?

Thank you for the support once again,
Luis

@lguilhermers

The plan is to introduce more fields for customization with the next releases, the initial release just included the parameters that were deemed most critical.

Note on the green roof: I just did a quick survey of the code and it looks like wall elements don’t have an option to model the solar reflection, and sensible heat contribution of vegetation [1][2], in contrast to horizontal elements like roofs and roads [3][4] where it is explicitly modeled. Furthermore, in UWG’s canyon solar calculations, reflected solar is only accounted for from roads, not wall elements [5].

I do see that green wall is mentioned in early UWG references, so either this was something that was removed at some point, or accounted for elsewhere. But, in general I’m not sure if that parameter will be available in the future.

S

  1. https://github.com/ladybug-tools/uwg/blob/master/uwg/element.py#L135
  2. https://github.com/ladybug-tools/uwg/blob/master/uwg/element.py#L140
  3. https://github.com/ladybug-tools/uwg/blob/master/uwg/element.py#L126
  4. https://github.com/ladybug-tools/uwg/blob/master/uwg/element.py#L128
  5. https://github.com/ladybug-tools/uwg/blob/master/uwg/solarcalcs.py#L89

Thank you for the further clarification, @SaeranVasanthakumar!

I will take a look on the parts of the code you sent. The green wall is not necessarily critical for my studies, but I was trying to follow the changes done from the Matlab version and confirm that I am having a correct interpretation of the python code and not missing anything basic.
Looking forward for the future updates and thanks again for working on enhancing it.

Regards,
Luis

Hi all,

First of all thank you very much for your work, you guys are awesome!

I’m looking to create my own “Building program” to do a simulation on DragonFly and I wonder if the technique cited here is possible today.

Regards,
Mathieu

1 Like

@mparis ,

All of the infrastructure to create programs and assign them to dragonfly objects is in place for the latest [+] plugins that are under development. But we haven’t done an official release of these latest [+] plugins yet and, at the moment, the newest Dragonfly[+] only connects to EnergyPlus and Radiance (we still have to add the UWG connection to Dragonfly [+] but this shouldn’t take too long given most of the E+ properties are translate-able to the UWG). In summary, the capabilities are coming soon but they aren’t quite ready for prime time yet.

Thank you for your quick answer!

I’m not sure I understand this sentence correctly :

Does this mean that I can define my building programs using Energy + components in the style of your “Full Building Energy Simulation”? (Hydra Viewer)

it builds the suspense haha Can i ask if it’s more of the order of weeks or months?? :grin:

Yes, you’ll be able to define energy simulation programs and apply them to Dragonfly objects. These Dragonfly objects can be exported to OpenStudio/EnergyPlus and our plan is to also make the programs translate-able to UWG format.

We’ll probably release a version with the energy capabilities on the time scale of weeks. Adding the UWG extension has a less determined timeframe. If all goes well, it will also be weeks.

Hi @SaeranVasanthakumar, I need to convert the airport to an urban epw file for running the UTCI analysis. Thanks for the amazing dragonfly, but I still have two questions about UWG 0.0.03 - (1) where can I check the thermal specification behind these preset building programs and ages? e.g., COP, infiltration, U-value, etc? (2) Which component can help me reschedule the occupancy of these buildings? My current project is in a medieval city, most of the residential buildings are without air-conditioning. Thanks!
image

@Kai_zp

The good news is that you can definitely customize the building model in UWG now. The bad news is that I don’t know how or if you can do this with the Grasshopper components since I didn’t work on the dragonfly-uwg connection. It does look like UWG accepts DF building model though, so I think you can just customize the program input in DF and connect it to the UWG components. @chris will have to clarify this for us.

If you know python, you can modify the UWG objects directly to create a UWG schema, which can be deserialized into a UWG model. Here’s a sample script that does exactly that.

1 Like

@Kai_zp ,

A few thoughts related to your questions:

  1. Dragonfly legacy is using a very old version of the UWG and so you won’t be able to do any of the customization that @SaeranVasanthakumar mentioned with the older dragonfly that you have there.
  2. The connection to the UWG in the new LBT Dragonfly plugin is currently only available in the development version of the LBT plugin. We are only a week or two away from another stable release of the LBT plugin. So, at the moment, you have a choice between either waiting another 2 weeks for the release of the LBT 1.2 plugin. Or you can install LBT 1.1 and run the “LB Versioner” component to update to the latest release. Here is an example file that uses the new UWG capability if you decide to run the “LB Versioner.”
  3. In the LBT plugin, you can check the general assumptions about constructions by looking at the various ConstructionSets for the different building vintages and climate zones. I know that the construction sets are generally a HB-energy object but they align very closely with the assumptions about the building envelope that are used by Dragonfly and the UWG.
  4. I didn’t expose the ability to customize the building schedules and individual material layers of constructions in the LBT plugin components but you will see that the new LBT plugin writes out a uwg.json that follows the new UWG Schema that @SaeranVasanthakumar documented. So, you can edit that JSON file in a text editor to add whatever custom extra schedules and constructions that you want and then re-run the .bat file that is next to the JSON in order to run the new custom JSON through the UWG and get an updated EPW file.
  5. I have generally found that the building envelope constructions don’t have nearly as large of an impact on the urban air temperature as the street canyon geometry, the pavement properties, the traffic schedule, and the rejection of air conditioning heat to the urban canyon. So I would recommend doing a sensitivity analysis with high-level properties before going deep into customizing things like the individual material layers of constructions or the building occupancy schedules.
  6. The UWG doesn’t have any native way to model natural ventilation but, if you really need to model this, you can approximate these conditions by setting the cooling set point to a very high number and boosting up the infiltration by a lot.
1 Like

Thank you so much @chris! Your answers are very clear to me. I definitely need to do a sensitivity analysis, not sure of how much contribution do any changes in building programs and ages will make. Good point on increasing the cooling set point, and I hope the future LBT can include more natural ventilation cases which is very common in European context. The UWG example file seems exactly what I am expecting for in the next round release. Tomorrow I am going to test uwg.json documented by @SaeranVasanthakumar, very excited now!

p.s., I have watched your presentation last week, wishing to echo a question raised by one audience that we are looking for new tutorials.

Very best,
Kai

Hi @chris,

As you have mentioned that we are only a week or two away from another stable release of the LBT plugin, will the ‘surface temperature’ and ‘microclimate map’ function in honeybee be updated too? Currently, I cannot get two components to run HBAnnuaLoads and HB ModelToOSM. It reported an error of failing to import lbt_recipes and no module named lbt_recipies_version.

In that regard, I have to use the legacy version at the moment. http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map&slide=0&scale=1&offset=0,0 (However, if I am not wrong, the UTCI in this legacy version was calculated without considering air temperature and relative humidity, hoping the new version can fix it.)

Best, Kai

Hi, as this topic is almost for a year ago, wondering if there is any update about controlling infiltration rate in recent version? I couldn’t find any.

You should probably start a new topic, @az.sanei . This topic should have been split into multiple ones since I have no idea which part of the discussion you are referring to now.

A post was split to a new topic: How to Re-run the UWG on Mac