ladybug-tools / uwg

:city_sunrise: The Urban Weather Generator (uwg) is a Python application for modeling the urban heat island effect.

uwg

The Urban Weather Generator (uwg) is a Python application for modeling the urban heat island effect. Specifically, it morphs rural EnergyPlus weather (.epw) files to reflect average conditions within the urban canyon using a range of properties including:

• Building geometry (including building height, ground coverage, window:wall area, and facade:site area)
• Building use (including program type, HVAC systems, and occupancy/equipment scheduling)
• Cooling system heat rejection to the outdoors (for Summer)
• Indoor heat leakage to the outdoors (for Winter)
• Urban materials (including the thermal mass, albedo and emissivity of roads, walls, and roofs)
• Anthropogenic heat from traffic (including traffic schedules)
• Vegetation coverage (both trees and shrubs)
• Atmospheric heat transfer from urban boundary and canopy layers

The original Urban Weather Generator was developed by Bruno Bueno for his PhD thesis at MIT. Since this time, it has been validated 3 times and has been enhanced by Aiko Nakano. In 2016, Joseph Yang also improved the engine and added a range of building templates.

This repository is a Python translation of the original MATLAB Urban Weather Generator.

Example

Here is a Python example that shows how to create and run an Urban Weather Generator object.

from uwg import UWG

# Define the .epw, .uwg paths to create an uwg object.
epw_path = "resources/SGP_Singapore.486980_IWEC.epw" # available in resources directory.


# Initialize the UWG model by passing parameters as arguments, or relying on defaults
model = UWG.from_param_args(epw_path=epw_path, bldheight=10, blddensity=0.5,
                            vertohor=0.8, grasscover=0.1, treecover=0.1, zone='1A')

# Uncomment these lines to initialize the UWG model using a .uwg parameter file
# param_path = "initialize_singapore.uwg"  # available in resources directory.
# model = UWG.from_param_file(param_path, epw_path=epw_path)

model.generate()
model.simulate()

# Write the simulation result to a file.
model.write_epw()

Installation

pip install uwg

QuickStart

import uwg

API Documentation

Local Development

1. Clone this repo locally

git clone [email protected]:ladybug-tools/uwg

# or

git clone https://github.com/ladybug-tools/uwg

2. Install dependencies:

cd uwg
pip install -r dev-requirements.txt
pip install -r requirements.txt

3. Run Tests:

python -m pytest tests/

4. Generate Documentation:

sphinx-apidoc -f -e -d 4 -o ./docs ./uwg
sphinx-build -b html ./docs ./docs/_build/docs

uwg's Issues

buildings area

Hi everybody,
I'm not sur I 100% understand the building model ou uwg. I saw in Joseph H. Yang master thesis that each type of buildign get its own area. So, does "charLength" of the simulation should be change depending on this building are ?
Best regards,
Simon

Change UWG_Matlab's road buffering method to match our revised UWG_Python method?

@hansukyang, @chriswmackey

UWG_Python uses the ".m" input method for reading inputs from UWG_Matlab, but uses its ".xml" method's for road slicing/buffering (as we discussed in issue #16). Therefore UWG_Matlab and UWG_Python currently have two different ways of modifying road thicknesses, for the ".m" file input. Should we change UWG_Matlab's code to be consistent with UWG_Python's?

I've already gone ahead and modified the code for my personal UWG_Matlab repo clone I've been using for testing. I realized when I started translating the surface flux calculations for the roads, that I needed to change the UWG_Matlab code so that I could compare the outputs of the two versions.

I basically moved the .xml method of road buffering to the .m read input section. And then modifed the procMat method to take the road objects created from the .m files.

What do you guys think? Is it important to try and keep both versions consistent, and make these sames changes in the original UWG_Matlab repo?

Sensible heat from trees not accounting for TreeCoverage fraction in UCMDef?

@hansukyang,

In the UCMDef.m module, the canyon sensible heat is calculated from the heat flux of the canyon components this way:

            % Sensible Heat
            obj.sensHeat = obj.Q_wall + obj.Q_road + obj.Q_vent + obj.Q_window + obj.Q_hvac + obj.Q_traffic + obj.treeSensHeat + obj.Q_roof;

https://github.com/hansukyang/UWG_Matlab/blob/b96bc2a8458ce10990d9bdbea16c5cef17628c50/SolarCalcs.m#L52-L54

Since this is the sensible heat for the total unit urban area, shouldn't the obj.treeSensHeat be multiplied by obj.treeCoverage? The obj.UCM.treeSensHeat variable is calculated in the SolarCalcs.m:

        % Vegetation heat (per m^2 of veg)
        UCM.treeSensHeat = (1-parameter.vegAlbedo)*(1-parameter.treeFLat)*UCM.SolRecRoad;
        UCM.treeLatHeat = (1-parameter.vegAlbedo)*parameter.treeFLat*UCM.SolRecRoad;

https://github.com/hansukyang/UWG_Matlab/blob/b96bc2a8458ce10990d9bdbea16c5cef17628c50/SolarCalcs.m#L52-L54

As you can see, it only takes into account the sensible, latent, albedo fractions, but not the ratio of trees in the urban area. So I believe when this is summed with the other canyon components in the UCMDef module, it may be overestimating the tree sensible heat load in the canyon heat balance.

I think this is done correctly, earlier in the code, when beginning the derivation of the total canyon Q:

            H1 = H1 + T_ubl*obj.roadArea*obj.uExch*Cp_air*dens_ubl; % Heat from UBL
            H2 = H2 + obj.roadArea*obj.uExch*Cp_air*dens_ubl;
            Q = (obj.roofArea+obj.roadArea)*(obj.sensAnthrop + obj.treeSensHeat*obj.treeCoverage);

https://github.com/hansukyang/UWG_Matlab/blob/b96bc2a8458ce10990d9bdbea16c5cef17628c50/UCMDef.m#L141-L148

But then, was omitted, when adding the sensible heat components up again at the bottom.

Let me know if I'm missing something here. (the code is sufficiently complex I wouldn't be surprised if this is somehow accounted for somewhere else!) thanks.

Saeran

ETA: Correcting total urban area to unit urban area.

How to commit with correct semantic versioning?

Question for you @AntoineDao

I got a whole bunch of changes to the code I want to commit, but I'm a little confused about how to do it with proper semantic versioning.

Are we using this commitizen tool that this link references - https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8? Or do we just have to modify our commit messages?

S

UWG error if soil depth < 3 in EPW file.

@hansukyang,

One of our users ran into trouble with an epw file that provided ground temperatures for only one soil depth, and not three as we have tested in the past.

Specifically, the monthly self.forc.waterTemp variable is taken from the 3rd soil depth in all cases, unless the number of soil depths is equal to zero (this is how the original matlab code treats this).

          if self.is_near_zero(self.nSoil):
                # for BUBBLE/CAPITOUL/Singapore only
                self.forc.deepTemp = sum(self.forcIP.temp)/float(len(self.forcIP.temp))
                self.forc.waterTemp = sum(
                    self.forcIP.temp)/float(len(self.forcIP.temp)) - 10.      # for BUBBLE/CAPITOUL/Singapore only
            else:
                # soil temperature by depth, by month
                self.forc.deepTemp = self.Tsoil[self.soilindex1][self.simTime.month-1]
                self.forc.waterTemp = self.Tsoil[2][self.simTime.month-1]

I changed the code so that the if condition is now if self.nSoil < 3: , that is, if any soil depth less then three is provided, the uwg will default to taking the self.forc.waterTemp, and self.forc.deepTemp using the method it uses for when no soil depth is provided in the uwg.

My changes are here: https://github.com/ladybug-tools/uwg/pull/95/files#diff-a226d4381c852ce81325ea5b7180fdc2R772

Let me know if this sounds okay, and if not, I'll revert the code.

Thank you,

Saeran

Overview of UWG_Matlab Translation

@chriswmackey

For the sake of keeping us organized, here's an overview of translation efforts so far. List below are all the .m files from the UWG_Matlab repo. X indicates what's been finished so far. I'll update whenever a file is finished.

X — 1BEMDef.m
X — 2Material.m
X — 3SchDef.m
X — 4readDOE.m
X — 5SimParam.m
X — 6Weather.m
7UWGParameter.m
8Building.m
9Element.m
10Forcing.m
11InfraCalcs.m
12Param.m
13Psychrometrics.m
14readUWG.m
15RSMDef.m
16SolarCalcs.m
17UBLDef.m
18UCMDef.m
19UrbFlux.m
20Def_Materials.m
21UWG.m
22readEP.m
xml_read.m ?
test_run.m ?
progressbar.m ?

Tree coverage

The UWG considers the tree coverage to define the latent heat flux in the urban area and the percentage of shaded surface in the canyon.
If I consider this study, The average UHI intensity decrease at increasing of the Tree coverage as expectable.
I downloaded this file and simply tried to modify the parameter related to tree coverage.
If I consider the default value of tree coverage equal to 0.2 the average monthly dry bulb temperature is 25.505 °C.
If I consider the modified value equal to 0.8 the average monthly dry bulb temperature is 25.515 °C.
I would have expected the exact opposite.
Even if I report all the hourly data for the entire month in a graph, there are no differences in terms of dry bulb temperature:

can You explain why?

Element.SurfFlux method never seems to use it's waterStorage calculation

Hey @chriswmackey & @hansukyang,

There seems to be an unused block of code in the element.SurfFlux method that is potentially causing inaccurate calculation of latent heat on horizontal surfaces.

Specifically, for horizontal surfaces, UWG_Matlab checks if the element's waterStorage (the meters of water film depth) is greater then zero, then uses that value to calculate the latent heat of the element.

if (obj.horizontal)     % For roof, mass, road
   % Evaporation (m s-1), Film water & soil latent heat
   if obj.waterStorage > 0
      qtsat = qsat(obj.layerTemp(1),forc.pres,parameter);
      eg = obj.aeroCond*parameter.colburn*dens*(qtsat-humRef)/parameter.waterDens/parameter.cp;
      obj.waterStorage = min(obj.waterStorage + simTime.dt*(forc.prec-eg),parameter.wgmax);
      obj.waterStorage = max(obj.waterStorage,0);
  else
      eg = 0;
  end               

soilLat = eg*parameter.waterDens*parameter.lv;
...
...
obj.lat = soilLat + vegLat;

The problem is that all elements have their waterStorage value hardcoded to 0 in the constructor, and I don't see it being ever called or reset again in the code. Additionally the wgmax parameter (max film water depth on horizontal surfaces), which we are hard-coding as 0.005 is also never used.

So if I'm interpreting the code correctly, it looks like UWG_Matlab always neglects the latent heat of water film on horizontal surfaces.

Should we be setting the waterStorage value for our horizontal surfaces? For example setting the road.waterStorage = wgmax when we are defining the roads in the UWG.m file. Or are we deliberating omitting this calculation?

-S

Implement unit and integration tests for UWG_Python

After a discussion with Mostapha, I'm going to swap out the temporary testing framework I wrote up with proper unit/integration tests with the pytest.py library. The new testing framework will look like the honeybee[+] tests.

TO DO:

• Make tests directory in UWG dir.
• Swap test.py for pytest.py
• Move test_uwg.py to UWG/test dir
• Sign up for travis ci.
• Test out test build during github push with travis ci
• Externalize tests from readDOE.py to own test file
• delete test.py
• Add parallel dir for tests and move all test_*.py files there

Soil layer Buffering and layer thickness control for .m file?

As the .xml input for UWG is phased out, note that buffering and layer thickness control for soil is only performed for .xml file as noted here

I'm not sure what prevented the integration of this same functionality to the .m inputs (have only started writing the code for this part), but see if it's possible to add this functionality to the .m file input, or add a note to make sure the method is not lost in the translation.

Ventilation and infiltration definitions in building.py

Hi,
looking at building.py, I found these args definitions in Building():
infil: Infiltration rate (ACH).
vent: Ventilation rate (ACH).
However, in Building() properties:
* vent -- Ventilation (m^3/s/m^2)
The same unit of measure is used for vent in SchDef. Then, it could be a mistake regarding the unit of measure of "vent".

Looking at the code in building.py, it would seems that this second definition is the correct one, indeed:
# total vent volumetric flow [m3 s-1]
volVent = self.vent * self.nFloor
volInfil = self.infil * UCM.bldHeight /
3600. # Change of units AC/H -> [m3 s-1]

However, why using a different formulation for "infil" and "vent"?

Many thanks,
G.

Python 2/3.6 compatibility issue

I just tried to run uwg in Python 3.6 and ran into this issue: https://stackoverflow.com/questions/43393764/python-3-6-project-structure-leads-to-runtimewarning

I think this only occurs when running uwg from the commandline, and can be addressed as indicated in the SO post.

S

Python 3 support

Putting this down as a reminder as I'm sure we all want to support Python 3 in the long run.

Add __repr__() and ToString() methods on the UWG Object

@saeranv ,
This doesn't influence the calculation but I think it will be nice to add these methods to the UWG object when we get the chance since these affect how the UWG object will be displayed in Grasshopper. You can see in the following image that I have added these methods for the dragonfly objects such that they display information about the object but the uwgObject output currently displays as a generic python object:

Dependabot couldn't authenticate with https://pypi.python.org/simple/

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Error in line 735

Has someone had error in line 735? We cannot model UWG 4 because of an error in Line 735. We have been told to close all office programms and to modify line 756, but it did not work. The error does not say anything apart from that.
Thank you!

Parameters to include in initialize.uwg

@chriswmackey I've noticed there a changes in the parameters we are including in the initialize.uwg vs intialize.m

I want to make sure I'm interpreting this correctly. These are the changes I've noticed:

SUBTRACTED

• maxdx = 250 # max dx (m)
• latAnth = 2 # non-building latent heat (W/m^2) (currently not used)

ADDED

• kRoad,1, # road pavement conductivity (W/m K)
• cRoad,1600000, # road volumetric heat capacity (J/m^3 K)
• OPTIONAL URBAN PARAMETERS
• albRoof,0.5, # roof albedo (0 - 1)
• vegRoof,0.1, # Fraction of the roofs covered in grass/shrubs (0-1)
• glzR,0.5, # Glazing Ratio. If not provided, all buildings are assumed to have 40% glazing ratio
• hvac,0, # HVAC TYPE; 0 = Fully Conditioned (21C-24C); 1 = Mixed Mode Natural Ventilation (19C-29C + windows open >22C); 2 = Unconditioned (windows open >22C)

On the latter set, I think the variables added here are good ones to improve: they can change between urban neighborhoods significantly, and also should have a pretty big impact on building energy/waste heat.

ETA: And I assume you're not including corresponding SHGC, and wall albedo as an optional parameters is b/c you're assuming they fraction of time that they get solar exposure is insignificant in terms of overall building energy and heat contribution to surrounding environment?

I'm going to add maxdx as a constant in UWG.py here and add the optional urban parameters when the DOE reference buildings are read in here. As latAnth is a variable that isn't used (according to the comment) I'll ignore it for now.

Let me know if this sounds correct.

S

Negative log values in Python throws error

Whereas in Matlab negative logs return a complex number.

I've run into the problem a while ago here: http://discourse.ladybug.tools/t/empty-epw-file/1835/20, but ran into it again for a different part of the code for this initialize file:

https://github.com/saeranv/Fermi/blob/master/fermi/initialize_TO.uwg

I have to see how Matlab handles negative logs in this specific error, and if it just returns the complex number and discards the i component for calculations, implement it in the Python code.

Add method to serialize uwg object back into .uwg parameter file

For the purpose of debugging from DF

Change all map lambdas to list comprehension in urbanWeatherGen

As noted here: https://stackoverflow.com/questions/1247486/python-list-comprehension-vs-map, using lambda for mapping is much slower then using list comprehensions. I've gotten a start on this with the code restructuring, but there's still plently more of these that I should change, so the UWG isn't slower then it needs to be. I've grepped all the uses of map lambda here:

element.py:            self.layerThermalCond = map(lambda z: 0, materialLst)   # vector of layer thermal conductivity (W m-1 K-1)
element.py:            self.layerVolHeat = map(lambda z: 0, materialLst)       # vector of layer volumetric heat (J m-3 K-1)
readDOE.py:    refDOE = map(lambda j_: map (lambda k_: [None]*16,[None]*3), [None]*16)     #refDOE(16,3,16) = Building;
readDOE.py:    Schedule = map(lambda j_: map (lambda k_: [None]*16,[None]*3), [None]*16)   #Schedule (16,3,16) = SchDef;
readDOE.py:    refBEM = map(lambda j_: map (lambda k_: [None]*16,[None]*3), [None]*16)     #refBEM (16,3,16) = BEMDef;
roadscratch.py:thickness_vector = map(lambda r: 0.05, range(road_layer_num)) # 0.5/0.05 ~ 10 x 1 matrix of 0.05 thickness
roadscratch.py:material_vector = map(lambda n: asphalt, range(road_layer_num))
roadscratch.py:pprint.pprint( map(lambda t: round(sum(t[2:6])/float(len(t[2:6]))-273.15,2), self.Tsoil))
utilities.py:        L = map(lambda r: r,gen_)
UWG.py:                self._init_param_dict[row[0]] = map(lambda r: utilities.str2fl(r[:24]),trafficrows)
UWG.py:                self._init_param_dict[row[0]] = map(lambda r: utilities.str2fl(r[:3]),bldrows)
UWG.py:        thickness_vector = map(lambda r: 0.05, range(road_layer_num)) # 0.5/0.05 ~ 10 x 1 matrix of 0.05 thickness
UWG.py:        material_vector = map(lambda n: asphalt, range(road_layer_num))

Revise time-step calculation in UWG

Errors are appearing in UWG due to explicit time-step calculation that should be changed to implicit. Copying and pasting time-step revision discussion by @hansukyang for reference:

"....in Building.m and UCMDef.m, there are two parts that were simplified, essentially assuming that the air temperature of a control volume is a weighted average of its surface boundary temperature, with each temperature value weighted by its area and the heat transfer coefficient, and adding in the heat generated. So for instance (from building.m):

        Q = obj.intHeat + winTrans + obj.Qheat-obj.sensCoolDemand;
        H1 = T_wall*wallArea*zac_in_wall + T_mass*massArea*zac_in_mass + T_ceil*zac_in_ceil + T_can*winArea*obj.uValue + T_can*volInfil * dens * parameter.cp + T_can*volVent * dens * parameter.cp;               
        H2 = wallArea*zac_in_wall + massArea*zac_in_mass + zac_in_ceil + winArea*obj.uValue + volInfil * dens * parameter.cp + volVent * dens * parameter.cp;
        obj.indoorTemp = (H1 + Q)/H2; <- this part here is the weighted averaging

where you can see how each term is summed. This doesn’t quite work for the urban boundary layer and solid element layers because the above assumes that within the time step (~5 min or so), the temperature within the control volume has equalized. Given the rate of change of other time-dependant parameters that changes its value every hour or so, this was assumed to be sufficient. "

Roof vegetation

Hi everybody,

I'm currently running sensitiviy analysis on the uwg code. I'm a bit surprised that the roof vegetation seems to have no influence on the results. I have found in the code :
self.BEM[k].roof.vegCoverage = self.vegRoof in the uwg.py
But I'm not sure this input is used. In the SurFlux function in the element.py, the following balance :
vegLat = self.vegCoverageparameter.grassFLat(1.-parameter.vegAlbedo)*self.solRec
shows that vegCoverage is used in the heat balance for the horizontal surface.

My question : does the parameter "vegCoverage" is also used for roof coverage ?

Best regards,
Simon MARTINEZ

Output building thermal loads and indoor temperature from the UWG

Hi everyone,
I'm Simon, a post-doc student working on urban heat island. I'm currently interesting in uwg code. I really appreciate your work... Congrats !
My question is : do you think it is possible to add output to the .epw file as IndoorTemp or Energy consumption ? I guess it is possible, so I'm wondering where to efficiently add this command ?
Bests
Simon MARTINEZ

Cannot run the example file

Hi!! My name is Athar and I wanted to run the UWG to understand how it works.

I am a beginner/ novice to python.

I cannot seem to run the example that's mentioned in the page. Would like some guidance on this.

"Here is a Python example that shows how to create and run an Urban Weather Generator object. The example script is available at resources/uwg_example.py. Run it through your command prompt in the main uwg directory with the following: python -m resources.uwg_example

from uwg import uwg

Define the .epw, .uwg filenames to create an uwg object.

uwg will look for the .epw file in the uwg/resources/epw folder,

and the .uwg file in the uwg/resources/parameters folder.

epw_filename = "SGP_Singapore.486980_IWEC.epw" # .epw file name
param_filename = "initialize_singapore.uwg" # .uwg file name

Initialize the UWG object and run the simulation

uwg_ = uwg(epw_filename, param_filename)
uwg_.run() "

Add floor-to-floor-height to UWG optional parameters

@chriswmackey has already done most of this, just have to add it to the overwriting loop.

Explicitly cast inputs into proper types in UWG

Based on issue raised with this PR: #72

@AntoineDao, wheb you accidentally passed integers into uwg, was the Exception that was raised this:

"The required parameters have not been defined correctly. Check input parameters and try again."

From here:

uwg/uwg/uwg.py

Lines 438 to 469 in 437934d

	# Required parameters
	is_defined = (type(self.Month) == float or type(self.Month) == int) and \
	(type(self.Day) == float or type(self.Day) == int) and \
	(type(self.nDay) == float or type(self.nDay) == int) and \
	type(self.dtSim) == float and type(self.dtWeather) == float and \
	(type(self.autosize) == float or type(self.autosize) == int) and \
	type(self.sensOcc) == float and type(self.LatFOcc) == float and \
	type(self.RadFOcc) == float and type(self.RadFEquip) == float and \
	type(self.RadFLight) == float and type(self.h_ubl1) == float and \
	type(self.h_ubl2) == float and type(self.h_ref) == float and \
	type(self.h_temp) == float and type(self.h_wind) == float and \
	type(self.c_circ) == float and type(self.c_exch) == float and \
	type(self.maxDay) == float and type(self.maxNight) == float and \
	type(self.windMin) == float and type(self.h_obs) == float and \
	type(self.bldHeight) == float and type(self.h_mix) == float and \
	type(self.bldDensity) == float and type(self.verToHor) == float and \
	type(self.charLength) == float and type(self.alb_road) == float and \
	type(self.d_road) == float and type(self.sensAnth) == float and \
	type(self.latAnth) == float and type(self.bld) == type([]) and \
	self.is_near_zero(len(self.bld)-16.0) and \
	type(self.latTree) == float and type(self.latGrss) == float and \
	(type(self.zone) == float or type(self.zone) == int) and \
	(type(self.vegStart) == float or type(self.vegStart) == int) and \
	(type(self.vegEnd) == float or type(self.vegEnd) == int) and \
	type(self.vegCover) == float and type(self.treeCoverage) == float and \
	type(self.albVeg) == float and type(self.rurVegCover) == float and \
	type(self.kRoad) == float and type(self.cRoad) == float and \
	type(self.SchTraffic) == type([]) and self.is_near_zero(len(self.SchTraffic)-3.0)
	if not is_defined:
	raise Exception(
	"The required parameters have not been defined correctly. Check input parameters and try again.")

If that's the case, this should be an easy fix.

-S

Incorporate mass balance for water vapor

To consider: incorporating a mass balance for water vapor, referenced in A new model of urban cooling demand and heat island - application to vertical greenery systems (VGS) . This would allow for a better modeling of Vertical Greenery Systems on cooling demand of buildings and urban microclimate (rather then through the input of a 'latent fraction' variable in current UWG.

ZeroDivisionError: float division by zero in Python UWG code

Hello, when i try to run UWG i've encountered an error building.py,

Traceback (most recent call last):
File "e:/ARCHIVE/BAP/uwg/Scripts/20_06_21-BC-UWG-BAP copy.py", line 89, in
custom_uwg(sample_directory)
File "e:/ARCHIVE/BAP/uwg/Scripts/20_06_21-BC-UWG-BAP copy.py", line 77, in custom_uwg
model.simulate()
File "C:\Users\Berke\AppData\Local\Programs\Python\Python37\lib\site-packages\uwg\uwg.py", line 1350, in simulate
self.RSM)
File "C:\Users\Berke\AppData\Local\Programs\Python\Python37\lib\site-packages\uwg\urbflux.py", line 38, in urbflux
BEM[j].building.BEMCalc(UCM, BEM[j], forc, parameter, simTime)
File "C:\Users\Berke\AppData\Local\Programs\Python\Python37\lib\site-packages\uwg\building.py", line 462, in BEMCalc
(dens * parameter.cp * (T_indoor - 283.15))
ZeroDivisionError: float division by zero

Error seems to be happening because of dens variable which is "Moist air density given dry bulb temp, humidity ratio, and pressure", where while calculating it in psychrometrics.py, the lines

def moist_air_density(P, Tdb, H): return P / (1000 * 0.287042 * Tdb * (1. + 1.607858 * H))

returns zero, because H value which represents "Number for Humidity Ratio (kgv/kgda)" becomes a very big bumber and python prints it as inf (before that it reaches 10e194ish numbers)

H value is entered in building.py to calculate dens value, in BEMCalc function. (dens = moist_air_density(forc.pres, self.indoor_temp, self.indoor_hum) # kgv/m3 ), H here corrensponds to "self.indoor_hum", which is also calculated later in the building.py function, self.indoor_hum = (self.indoor_hum + (simTime.dt / (dens * parameter.lv * UCM.bldHeight)) * (QLintload + QLinfil + QLvent - Qdehum)),

this function fails because of the sharp changes in parameter.lv value which is "latent heat of evaporation [J kgv-1]" . However, , could not find the exact reason why parameter.lv value's incorrect calculation, as i couldn't find where it was set.

Thanks for your reply, have a nice day!

Initialize Precipitation values with array of zeros.

We're recently had two Ladybug users that have run into issues with the UWG while using customized EPW files (i.e morphed future projection data) that lacked a column for precipitation. I encouraged both to simply add zero values for precipitation in the original file to get the simulation to work.

As we've discussed previously, the current implementation of the UWG doesn't use precipitation data due to the difficulty in validating latent heat impact, the poor quality precipitation data from weather sensors, and the marginal impact it has on UHI.

Despite this, the weather object in UWG is still reading in the precipitation values from the EPW file, which is causing issues for custom EPW files. I propose we simply initialize the precipitation array with zeros to avoid this error. I don't think we should get rid of it completely, since there's a lot of (commented) code in the current UWG that refers to the precipitation array, that provides useful context regarding UWG's handling of precipitation and latent heat.

@hansukyang, do you see any problems with this?

S

Copy z_meso.txt into the UWG Folder

@saeranv ,
In addition to the readDOE.pkl, I have realized that this z_meso.txt file is necessary to run the UWG. I am just thinking that we should find some way to package the minimum number of things people need to run the UWG so that we don't end up creating extra unnecessary folders in the Rhino scripts directory. Another solution might be to just make a resources subfolder within the UWG folder that contains the resources that are critical for running the engine (like the readDOE.pkl and z_meso.txt).

Also, I should say that, right now, I'm overwriting the RESOURCE_PATH of the UWG object in GHPython in order to avoid copying the entire resource folder in the the Rhino scripts folder. Maybe we should have the default resource path point to such a small subfolder within the UWG folder and, on the github here, we have the more detailed resource folder that we use for testing and generating the pickle files.

What are your thoughts here?

Translate sign(1., zenith) from matlab to python.

From solarcalcs.py

elif (abs(self.zenith) < 1e-6):
#TODO: Need to translate sign(1.,zenith) from matlab
raise Exception("Error at zenith calc.")
#tanzen = sign(1.,zenith)*math.tan(1e-6);

I still need to understand and translate sign(1.,zenith) in python. Currently if this condition is met, an error is raised.

Read and reference US DoE building standards for UWG

Write a translation or develop a new method to read US DoE building read from DOERefBlds excel files, and translate it for UWG inputs.

DOERefBlds here:
https://github.com/hansukyang/UWG_Matlab/tree/master/data/DOERefBuildings

Currently this is handled by the following files in the original UWG:
https://github.com/hansukyang/UWG_Matlab/blob/master/RefDOE.mat
https://github.com/hansukyang/UWG_Matlab/blob/master/readDOE.m

Add the Ability to Model Naturally Ventilated Building Typologies

For a while, I have been curious about the effect of natural ventilation on UHI and I think that we should find some way of adding this in as we build future versions of the UWG. I think we can do it by simply cutting out the cooling and boosting up the airflow to the indoors when the indoor temperature gets above a certain threshold (using the same mechanism that we currently use to account for infiltration). We can have the airflow calculated based on simple orifice equations, which are well-documented in the EnergyPlus reference on WindAndStack objects:
https://bigladdersoftware.com/epx/docs/8-7/input-output-reference/group-airflow.html#zoneventilationwindandstackopenarea

UWG EPW double `\n` per line

I was experimenting with Dragonfly/UWG and was parsing EPW files using pandas (standard pd.read_csv()) and noticed it would work fine on normal EPWs but the morphed EPWs resulting from Dragonfly/UWG would break reader.

After some investigating I noticed that lines in UWG produced EPWs are escapes like so \n\n as opposed to \n in normal EPWs.

This is a cosmetic issue when looking through the EPW file but if we are aiming to then parse and compare with standard EPWs after running simulations this could be problematic.

Change name of package to uwg

Per discussion with @chriswmackey, we are changing the name of this package from urbanWeatherGen to a PEP8 convention-friendly uwg.

Object-Oriented API on top of UWG to accept inputs from many sources

From @chriswmackey:
"...improve the methods for inputting variables into the engine. In particular, I think that building an object-oriented API on top of the engine will make it easier to accept inputs from many sources - whether they are XML files, JSON files, Excel interfaces, or Grasshopper components that assemble python objects to go directly into the engine."

@chriswmackey, Does this mean you're intending on creating a "core" dragonfly class that uses (for example) pyeuclid.py for geometry operations and then a separate class/repo of dragonfly_grasshopper / dragonfly_dynamo etc?

Test failing 2.7 for TestDragonfly class

@chriswmackey

Failing test here: https://travis-ci.org/ladybug-tools/uwg/jobs/660918297

Is the TestDragonfly class here something you've added? It seems to be failing in the Python 2.7. If not, I have a very bad memory since I don't remember writing this code. It may have something to do with changes I made to the readDOE import to solve a problem to address a user's problem here: https://discourse.ladybug.tools/t/readdoe-pkl-mood-issue/8615.

I made the decision to pull this in even with the failing test because it seems to be an edge case, and I didn't want the LB user to wait while we figure out what's wrong here.

Dragonfly for grasshopper improvement request

After a long exchange of messages with @saeranv, I think it would be useful to add a component that allows modifying the building’s cooling set point and the envelope construction properties…
Considering the dragonfly as it is now, it is not possible to conduct a sensitivity analysis such as, for example, the one conducted in this study from which I extracted the following table (the values that the dragonfly allows you to modify are highlighted in yellow):

From the above-linked paper, the cooling setpoint seems to be relevant in terms of the average UHI effect.
It could be useful to modify also the characteristics of the building envelope.

In defining the 3D model of the urban district, considering the structure of the DF Edit Typology Envelope component and that of the DOE ref building LocationSummary.csv, it could be useful to add these options that could differ from the reference DOE building (the most relevant in yellow):

Furthermore, considering the DF City From Parameters component, that allows defining the city starting from numerical descriptions, it could be useful to add the possibility of considering the bldg characteristics with the following two components (one new on the left that is similar to "DF Edit Typology Envelope" used in the 3D model and a modified version of the existing DF City From Parameters component on the right):

Add a log file option to the CLI commands

It has been very difficult to understand what has causes the UWG to fail when it does. Writing out the exception to a log file as seen here in the honeybee-energy simulate command would be very helpful.

Possible error in uwg.py

Hi,
I found this in uwg.py.
# fraction of vegetation (tree & grass) coverage on unbuilt surface
road_veg_coverage = self.vegcover / (1 - self.blddensity)
road_grass_coverage = self.treecover / (1 - self.blddensity)
road_tree_coverage = self.grasscover / (1 - self.blddensity)
It would seem that self.grasscover and self.treecover are inverted.

Thanks,
G.

Put line breaks into the progress bar?

@saeranv ,
Do you know if it is possible to input line breaks in the progress bar output? Without the breaks, it creates something that looks a little strange on the Grasshopper component:

With some line breaks, I imagine that it will look consistently like this:

Runtime Error Argument out of range

Hi, I am having some issues when installing Dragon Fly in Grasshopper. It says Runtime Error, ArgumentOutOfRangeException.I attach an image
Has anyone had the same problem? Thank you

Change the Pickled DoE Buildings to Reference Classes With Capital Letters

It seems that they are referencing classes with lower case letters at the moment:

albroof and c_exch on daily maximum air DB temperature in UC

According to #18, in UWG the roof albedo impacts the sensible heat of the roof, which indirectly affects the environment in the UC.
Thus, I supposed that in UWG the primary effect on UCBM of higher albroof value in summer should be lower UC air temperatures due to the reduction of the BEM cooling energy demand and the related heat waste.
In order to verify this, I made a simple parametric simulation by varying the albroof value in the attached code.
Surprisingly, I have obtained the exact opposite: the higher the albroof value, the higher the maximum UC air temperatures.
I checked the code in element.py and it seems correct to me.
Can You explain why this happens?

I have also noticed that in the code the default value for c_exch is set to 1. However, I found lower values in the literature (0.3 from the most recent works of Bueno et al. and Mao et al.). So I have assumed 0.3 since it seems to have a strong impact on the UC maximum temperatures. However, also assuming c_exch = 1, I have obtained similar results (even if with lower differences).

This is the simple code I have used to explain this issue (only one day of simulation is used here for sake of velocity, but similar results are obtained on the other summer days). I have used the "Ancona 161910 (IGDG)" EPW from E+ database.

model = UWG.from_param_args(bldheight=10, blddensity=0.5, vertohor=0.8, grasscover=0.1, treecover=0.1, zone='1A', epw_path=epw, month=8, day=1, nday=1, dtsim=150, c_exch=0.3)      
model.albroof = 0.9
model.epw_precision = 3    
model.generate()
model.simulate()
model.write_epw()

python 3.7.3 on windows machine

I'm trying to run uwg on a windows machine using anaconda (Python 3.7.3).
I wrote a python script to randomize some values of the param file. At the end of the code i put the last line of the example file
uwg_.run()
When i run the code on the windows machine using Python 3.7.3) i'm experiencing the error below.
No errors with the same code on linux machines.
No errors on windows machine using Python 2.7
Regards

Traceback (most recent call last):
File "C:\Users\P002846\Anaconda3\lib\runpy.py", line 193, in run_module_as_main
"main", mod_spec)
File "C:\Users\P002846\Anaconda3\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\butta_via\uwg-master\resources\uwg_example.py", line 11, in
uwg.run()
File "C:\butta_via\uwg-master\uwg\uwg.py", line 972, in run
self.simulate()
File "C:\butta_via\uwg-master\uwg\uwg.py", line 883, in simulate
self.UCM, self.UBL, self.BEM, self.forc, self.geoParam, self.simTime, self.RSM)
File "C:\butta_via\uwg-master\uwg\urbflux.py", line 26, in urbflux
BEM[j].building.BEMCalc(UCM, BEM[j], forc, parameter, simTime)
File "C:\butta_via\uwg-master\uwg\building.py", line 130, in BEMCalc
self.logger.debug("Logging at {} {}".format(name, self.repr()))
File "C:\Users\P002846\Anaconda3\lib\logging_init.py", line 1365, in debug
if self.isEnabledFor(DEBUG):
File "C:\Users\P002846\Anaconda3\lib\logging_init_.py", line 1619, in isEnabledFor
return self._cache[level]
AttributeError: 'Logger' object has no attribute '_cache'

Bug in write_epw that Fails to Write Integer Wind Values

@saeranv
There seems to be a bug in the write_epw method of the UWG (line 778). The wind data in the weather file needs to be converted to a float in the event that it gets interpreted as an integer. Once I cast the wind value to a float, everything worked like a charm.

Add test for DissipationBougeault method RSM.def

The following, deeply nested code block in RSM.def, works a lot better in Matlab then Python, because Matlab doesn't use significant white space to indicate the start and end of iterative loops.

As a result it's very easy to introduce subtle errors in it's python translation, and during testing I found this was the part of the UWG code that had the most errors. There needs to be a number of dedicated tests to ensure it's consistency with the original version.

No changes in simulation results when improving system efficiency or increasing thermal insulation

Hi everyone! I'm a Master student from Italy and I started to use the UWG Python version to assess the UHI effect on local case studies for my Master thesis. I'm new to programming and to Python, so I hope that my question won't seem too banal.
My thesis goal is to assess the UHI effect on local buildings that I precisely characterized from the geometrical, architectural and usage point of view (basically, beside filling in the initialize file, I also changed the default values of DOE Reference Buildings folders to make them more realistic and similar to the buildings of my city) . Beside the current situation, I wanted to test the implications on UHI effect of different retrofit scenarios (condensing boilers, heat pumps, an increase of thermal insulation, etc), but I'm facing a problem. The results that I'm getting for the different scenarios are the same for the "base" scenario.
At first, I thought it was my fault, maybe putting the wrong values, but I did many simulations and the situation doesn't change. So far, I tested 5 situations:

Scenario 1 : changing from gas boilers (Heating efficiency=0.6) to condensing boilers (Heating efficiency=0.8) --> no changes
Scenario 2: changing from gas boilers (Heating efficiency=0.6) to biomass boilers (Heating efficiency=0.62) --> no changes
Scenario 3: changing from gas boilers (Heating efficiency=0.6) to heat pumps (Heating efficiency=3.18) --> no changes
Scenario 4: changing from gas boilers (Heating efficiency=0.6) to heat pumps (Heating efficiency=3.18)  + adding external thermal insulation to walls (Resistance values about 2.7 compared to previous resistance about 0.90) --> no changes
Scenario 5: changing from gas boilers (Heating efficiency=0.6) to heat pumps (Heating efficiency=3.18)  + adding external thermal insulation to walls (Resistance values about 2.7) + considering PV integrated into the roof (Albedo roof = 0.3) --> slight changes

To be sure that I called the right file among all building typologies' .csv files, last time I tried something "drastic": I put the values of my building in each building typology and each column of climate zones, so it's like there is only one building typology with its characteristics in the program. However, the results were once again the same.
Given this, I started to question the relevance of thermal insulation and system efficiency on final results or the way the program itself accounts for them in the outdoor air temperature calculation, also because I've learned from literature that building output to canyon influences the UHI effect. Enhancing system efficiency (for example using heat pumps) should have slightly reduced canyon temperatures since heat pumps extract heat from the canyon instead of releasing it. Has anyone ever faced something like this? Or made thoughts about the relevance of system efficiency and thermal insulation on the phenomenon/how UWG deals with it?
Thanks in advance for the availability. I'm here to learn about the program and the UHI phenomenon itself, so every answer is welcomed.

Eleonora

Rounding precision for the readDOE values from the excel sheet differ from Matlab and Python

Discussed in the #23 PR. Since we're getting around 11 digits of accuracy with the current method, for now this isn't an urgent issue, but I'd still like to document the problem here in case it pops up again.

Both Matlab and Python are using 64 bit floating point numbers, approximately 15 to 16 digits of precision each. Which means as long as the operations are consistent, the values outputted from the UWG_Matlab should be consistent with the UWG_Python up to 16 digits of precision.

And yet there seems to be some sort of rounding precision difference in the readDOE function. Below is an example of a difference occurring at 11 sig dig for the coolCap value, when they should be consistent for 16 - 2 = 14 sig dig:

//HVAC_matlab  vs HVAC_python
193.9309400000000 									 
193.930939999999992551238392479717731475830078125 	

//AreaFloor_matlab vs AreaFloor_python
2090.320422895048
2090.3204228950498873018659651279449462890625

//coolCap_matlab vs coolCap_python (HVAC*1000/AreaFloor)
92.775699780711108 
92.775699780710993991306168027222156524658203125

All my other floating point calculations have been working, which has allowed for a easily computable tolerance calculations when comparing the matlab vs python values in the testing framework. So it'd be good to figure out what exactly is going wrong here, to return to that level of consistency/accuracy.

Move BEM object parameter input to own method

To resolve @chriswmackey's problem here: ladybug-tools/dragonfly-legacy#34

Moving the building loop to it's own method should solve this.