computation of verTohor

[HibaHamdi09]

I’m using your model in the framework of my PhD to produce air temperature maps and aim to compare the simulated maps with measurements made by ground stations. To be sure to use the model properly, I have few questions.

First question: I would like to know if the calculus I made for the parameter VerToHor is correct.
I referred to the definition “verToHor: Vertical-to-horizontal urban area ratio (facade area/urban area). The resolution of the urban area that I am working on is 200 by 200m.

I calculated the total length of facades within my area
I calculated the total facade area = total length of facades x average building height (for the same area)
I calculated verToHor by dividing the facade area by the area of ​​my zone, which is 200x200m

Here : https://urbanmicroclimate.scripts.mit.edu/uwg_parameters.php#urbanArea , they talk about a weighted average building height. Thus, I was wondering if this ponderation step should be added in my verTohor computation.

Second question: in the epw file, I set the dates in UTC and in the header I defined the UTC zone as +0. This choice was made to avoid problems with the daylight saving time change. Does it seem correct to you?

Thank you in advance for your help with this.

Best regards,
Hiba

[biglimp]

Yes, your verToHor seems correct.
Regarding the epw-file I think it should be possible to use UTC = 0 but I am not sure. The UWG model is not written by our team so we dont really know. I suggest that you try other UTC and see what happens. UTC and see what happens. With that said, it seems to be the only place where time is set so probably you will be successful if you set UTC so that it matches the data in your epw-file.

Your work sounds interesting. Please share when you have something to show us. Maybe your data and workflow can be made into a tutorial for others?

[biglimp]

I think that is a typo in their documentation. verToHor can be higher than 1. You should contact them and ask them to change this.

[HibaHamdi09]

Ok, thank you.
Have a good day

[CsillaVG]

I am sorry for butting in. In epw, time refers to local standard time without daylight saving. The offset (formerly from GMT, now UTC) is set in the header.

MIT's documentation is also erroneous regarding the neighborhood characteristic length. It is not the radius of the urban area modeled, but the side of the square encompassing the neighborhood.
See the related discussion here: https://githubhot.com/repo/ladybug-tools/uwg/issues/18?utm_source=pocket_mylist

Good luck with your thesis!

[HibaHamdi09]

Thank you for your assistance and encouragement!

To avoid confusion, I transform the time of my data into UTC, and I put UTC in the header of epw. at 0.

I think it has been corrected. "The characteristic length is the dimension of a square that encompasses the whole neighborhood" (https://www.ladybug.tools/uwg/docs/uwg.uwg.html#uwg.uwg.UWG.bld)

[CsillaVG]

It's great to hear that the meaning of this parameter has been corrected by the Ladybug developers.
However, I would advise against transforming your climate data to UTC=0 and defining the UTC value in the header. The climate data (the body of the epw file) needs to be in the local standard time of the place it refers to.

Here is a related discussion: https://unmethours.com/question/19251/energy-plus-weather-files-utcgmt/
And here is a python code on how pvlib deals with/imports epw files: https://pvlib-python.readthedocs.io/en/v0.9.0/_modules/pvlib/iotools/epw.html

I hope it helps.