Parameters to include in initialize.uwg

[saeranv]

@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

[saeranv]

Also, what is charLength supposed to be exactly?

According to the intialize.uwg comments it's a radius.
charLength,1000, # radius defining the urban area of study [aka. characteristic length] (m)

But the area formula where this is used is actually like this:
area = bld*charLength^2*bldDensity*bldHeight/h_floor; % building floor area

I'm not sure if this matters in terms of the overall simulation. But for consistency's sake we should either change the description to be "square edge length" or change the default charLength to be 500m and formula to be pi*(charLength)^2.

[chriswmackey]

@saeranv ,
Sorry for he late response here.
The initialize.uwg was mostly meant to be my personal take on the initialize.m file that @hansukyang originally developed. I most added a few parameters that I know most architects/planners are interested in testing on a regular basis (even though I know that their impact is often small).

I had suggested taking out the max dx because I couldn't think of a dragonfly user who would use it who would not also be enough of an expert to use the API version. In hindsight, we may want to leave the anthropogenic latent heat exposed. I had never used it in any of the models that I ran but, if we have a case where the heat in the canyon is caused by a large crowd of people (and not cars/busses/street lights), then it's useful.

It looks like I mis-labeled the characteristic length and that it's actually supposed to be the dimension of a square that encompasses the whole neighborhood. Not the radius. Sorry for the confusion.

[saeranv]

@chriswmackey

Sounds good! I added the latent anthropogenic heat back in and re-labeled the characteristic length.

Note that the latAnth right now is being passed to UCMDef, but not being used in any calculations anywhere (as far as I can see). So it's just a placeholder for now, that we can tackle later.

Also I added all the parameters that you suggested into UWG.py (albRoof, vegRoof, glzR, hvac), but decided to not actually integrate it into the code for now. The reason is that, certain parameters, like hvac or glzRatio will overwrite the defaults that UWG.py is pulling from the reference DOE buildings. It's better to keep those variables consistent with DOE defaults for now so that we can test and compare it against the original UWG.m.

[chriswmackey]

@saeranv ,

Thanks for digging into this and for updating the .uwg sample file.
I can see why latent heat might be ignored. It doesn't affect the temperature within the urban canyon and it only affects the humidity. Right now, I'm not sure if the humidity is being adjusted at all in the UWG.

Ignoring certain parameters sounds good for now. I agree that we should have a system for defaulting to the DoE templates if there's no user input. Perhaps we have an option for people to just input "default" instead if a specific number for glazing ratio.

[hansukyang]

FYI,the latent heat calculation was removed for a few reasons - the calculation originally included didn't seem very complete (e.g. for Cambridge, how one would account for Charles River), the latent heat calculation wasn't validated, and the impact on the urban temperature was minimal. I think it may affect how well systems like evaporative condensers might work but I think there wasn't enough in the model to try to justify incorporating this feature. Joseph

…

On 15 October 2017 at 10:43, Chris Mackey ***@***.***> wrote: @saeranv <https://github.com/saeranv> , Thanks for digging into this and for updating the .uwg sample file. I can see why latent heat might be ignored. It doesn't affect the temperature within the urban canyon and it only affects the humidity. Right now, I'm not sure if the humidity is being adjusted at all in the UWG. Ignoring certain parameters sounds good for now. I agree that we should have a system for defaulting to the DoE templates if there's no user input. Perhaps we have an option for people to just input "default" instead if a specific number for glazing ratio. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALUG7aUEssm1E7xrAQRjO5LrS626JXEqks5sskQ7gaJpZM4Px6ld> .

[saeranv]

@hansukyang

I just added the optional parameters into the UWG and wanted to clarify a few things before I close this issue.

And, for reference, this is how our initialize file looks like right now: https://github.com/ladybug-tools/urbanWeatherGen/blob/master/resources/parameters/initialize_singapore.uwg

1. Regarding your removal of certain latent heat calculations: are there any references to latent heat in our initialize.uwg file that are not being used in the simulation? We want to make sure to inform users if any of these parameters aren't being used in the engine.
   Specifically, I can tell latGrss is being used to calculate surface flux on the elements with vegetation, and that LatFOcc is being used to calculate building internal loads. However I'm not so sure if latAnth, and latTree are being used. They are added to the UCM.latheat (urbflux.py line 48) but then I don't see the UCM.latheat variable used anywhere.

2. For our optional parameter of the hvac:
   hvac, , # HVAC TYPE; 0 = Fully Conditioned (21C-24C); 1 = Mixed Mode Natural Ventilation (19C-29C + windows open >22C); 2 = Unconditioned (windows open >22C)
   Is this being used anywhere? Or is this something that is a hold-over from an older version of UWG?

Thanks for being so generous with your help! This whole project would be a lot more complicated without your input. Let me know if you need further clarification.

[chriswmackey]

I just wanted to update this issue now that @saeranv and I have had a discussion in person.

We will take out all of the latent heat inputs since these are no longer included in the UWG calculation.

The HVAC input (with the option for natural ventilation) was something that I had added to the list because I was curios abut how natural ventilation affected UHI. However, it seems like it will take a fair amount of editing of the UWG core to incorporate this in so I have created a separate issue and we can address this far in the future after we have a minimum viable version working:
#49

We will take out all inputs related to the roof albedo and roof vegetation cover since @hansukyang simplified the UWG during his thesis to only model two outdoor urban air volumes: the urban boundary layer and the urban canopy layer. As such, all heat that hits the roofs is currently going to the urban boundary layer and is not really affecting the calculation. So we will remove the inputs related to roof vegetation cover and roof albedo.

We realized that there are a number of inputs related to the infinite urban canyon in the UWG that should be calculated with a weighted average of typology facade area but are currently calculated with a weighted average of floor area (as per the ratio of typologies input). Specifically, these inputs are :
Glazing Ratio
SHGC
Wall Albedo
So we plan to add these inputs into the initialize.uwg so that they can override this current default.

[hansukyang]

Thanks for the clarification Chris. I thought I must have added the HVAC input since I didn't remember that in the original version but couldn't quite remember so this helps. With regards to the roof characteristics, since both the urban canyon and roof energy connects to the boundary layer I'm not sure if complete removal would be faithful to the original UWG physics if you mean to completely remove roof-related input. If I remember correctly, only the sensible heat energy from the roof to the boundary layer so that it does contribute slightly to the urban heat island whereas the radiative heat from the roof wouldn't (reflected solar and long-wave). This is due to the boundary layer being relatively thin (< few km) and largely transparent in the IR range. Not sure if I understood your comment correctly but thought I'd mention it. Joseph

[chriswmackey]

@hansukyang ,
Thanks for the response and what you said about the radiative portion makes sense. In which class would I find the amount of sensible solar transferred from the roof to the UBL? I can't seem to find it anywhere.

[hansukyang]

In the UCMDef.m module, line 182 takes the sensible heat from each building type: obj.Q_ubl = obj.Q_ubl + BEM(j).frac*(BEM(j).roof.sens*obj.bldDensity+building.sensWaste*(1-obj.h_mix)); This then gets added in line 191 to the advective exchange: obj.Q_ubl = obj.Q_ubl + obj.uExch*Cp_air*dens*(obj.canTemp-T_ubl)*(1-obj.bldDensity); So I don't think there is a variable that keeps track of only the sensible heat from the roof to the UBL since it's lumped together but this should be where it's accounted for.

…

On 5 June 2018 at 01:02, Chris Mackey ***@***.***> wrote: @hansukyang <https://github.com/hansukyang> , Thanks for the response and what you said about the radiative portion makes sense. In which class would I find the amount of sensible solar transferred from the roof to the UBL? I can't seem to find it anywhere. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALUG7e7I26QInsUvCxmkCClqhWRCf5GAks5t5WgLgaJpZM4Px6ld> .

[saeranv]

@hansukyang @chriswmackey

Based on this discussion I've made what I think should be the final change (for this release) of the initialize.uwg file with this update #54. In the end, there's only been minor changes: I added/kept all the optional building parameters we discussed (albRoof, vegRoof, glzR, albWall, SHGC), and took out the hvac input until Chris adds the natural ventilation input.

As discussed above the roof parameters (albedo and vegetation) impact the roof sensible heat, which indirectly effects the environment in the urban canopy, so we will keep that.

And I've also kept the latGrss and latTree factors. It turns out they also are effecting the canyon temperatures, albeit in a unexpected way. The latent heat calculated is never used in the UWG simulation, BUT the latent fractions are used to calculate the sensible heat fraction of the trees, and vegetation on the ground.

So in solarcalcs.m tree latent fraction is used to calculate the sensible heat of trees:

% 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;

And the grass latent heat is used to calculate the heat flux in element.m (presumably for the road elements):

 vegSens = obj.vegCoverage*(1.-parameter.grassFLat)*(1-parameter.vegAlbedo)*obj.solRec;

I only figured this out after I had removed the optional parameters, and my testing framework started complaining. So I can confirm that these latent fractions are indirectly effecting the final EPW. @chriswmackey it might worth clarifying in Dragonfly that this input is only used to calculate sensible heat, and won't account for latent effects like evaporative cooling.

Anyway, with that I think this version of the initialize.uwg looks complete enough for this release. Let me know if you guys have any further revisions or comments.

Saeran

[chriswmackey]

@saeranv ,

Thank you for all of the clarifications. That is good to know about the latent vegetation fractions and I will add these inputs back into the Dragonfly Vegetation Parameters with a note that the latent heat does not affect the humidity within the resulting EPW. It only impacts the temperature.

I will also add a component that allows users to edit all of the envelope properties of a given typology (glazing ratio, SHGC, wall albedo, roof albedo, roof veg fraction). Is there no input for wall veg fraction?

The last thing that I want to do with these envelope parameters before we officially say that the Dragonfly workflow is complete is that I see the way you have implemented it, @saeranv , is that you use the glazing ratio, SHGC, etc. to override the envelope inputs on all of the typologies:
https://github.com/ladybug-tools/urbanWeatherGen/blob/master/UWG/UWG.py#L532-L542
However, Dragonfly is structured to take different envelope properties for different typologies (ie. you could have all residential typologies with a 20% glazing ratio and all commercial typologies with an 80% glazing ratio). So I think I will add some code in the Dragonfly "Run WUG" component that automatically overwrites the glazing ratio of each typology after init_input_obj() is run. This way, it will use the facade-area-weighted glazing ratio across all typologies in the "infinite urban canyon" calculation but it will use the glazing ratio of each individual typology when running the BEM for each typology. Let me know if this makes sense @saeranv .

[saeranv]

@chriswmackey

Yes, there doesn't seem to be any input or calculations that take into account the wall veg fraction.

As for your second point, I'm glad you're customizing the object, this was actually something I was going to suggest that you do because as you point out, right now it's too generic. The reason it is that I didn't want to start making the initalize.uwg input sheet complex, with all the building typology parameters further subdivided by which typology to apply them too. I'll comment more on this method in the Dragonfly issue you started.

For now, since I think the initialize.uwg file seems good enough, I'll close out the issue, and any further revisions can be captured with a new issue.

Thanks guys!

[chriswmackey]

@saeranv ,
Sorry for not noting this sooner but there's one last parameter that we forgot to include, which is the floor-to-floor height. I just added it here:
ee0f2b3

And I use it to set the average floor-to-floor height in Dragonfly.