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

[saeranv]

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.

[chriswmackey]

@saeranv , I remember that @hansukyang explained to me why he did not exposed this as an input on the excel and .m interfaces. If he manages to read this post, he can elaborate more but my understanding is that the thickness of the street construction really should not change between simulations because, for the purposes of our simulation, the ground is infinitely deep. Furthermore, if you give people the option of making the ground thicker, it could cause the heat flow solver to fail because (much like EnergyPlus) it is really only meant to handle thicknesses less than a half-meter or so. So he just fixed the depth of the ground at a specific thickness.

[saeranv]

@chriswmackey I see, so the .m file method for calculating soil thickness is the one we want to keep, because it maintains an assumed road construction depth.

In this part:

Furthermore, if you give people the option of making the ground thicker, it could cause the heat flow solver to fail because (much like EnergyPlus) it is really only meant to handle thicknesses less than a half-meter or so. So he just fixed the depth of the ground at a specific thickness.

Do you mean street depth here, not ground depth? Is UWG changing the ground depth at any point? In the code it looks like we are only fixing/changing the ground temp that is under the road construction, and road thickness:

            % For .m file, assume the soil depth is close to one of the ground
            % soil depth specified in EPW (0.5, 1.0, 2.0)
            for i = 1:n_soil
                if sum(road.layerThickness) <= depth(i)
                    soilindex1 = i;
                    break;
                end
            end

[hansukyang]

Hi,

Sorry for the late reply. This part of the code is a bit messy because I was trying to juggle maintaining the legacy interface (XML) and code updates. Background: Bruno had originally assumed a constant ground layer temperature at a value equal to the average air temperature over the year and connected to a road layer which I believe was fairly thick layer. On the other hand, I found that the EPW file included values for ground temperature (for TMY2 type only) for each month of the year, at depth of 0.5, 1, and 2m, so I tried to incorporate this into the code. So the two problems that I was addressing was that 1) since the ground layer tended to be very thick, it didn't reflect the high temperature that the road surface can get to (think of fresh asphalt surface on a sunny day) and 2) rather than a constant ground temperature over the year, monthly variation would be more accurate.

After discussion with Les, we thought having road layer broken down into several layers of thickness of about 2 inches (or specified as 'max_thickness', I believe) would work, and since the user tended to specify arbitrary road layer thickness, what the code is doing is adding more layers until the total thickness reaches any one of 0.5, 1.0, or 2.0 depth where the lowest layer can then be fixed to the ground temperature.

So hope this explains what is going on a bit more - not sure if I answered the question (long story short - ground depth is not being changed, and the road layer is being both divided up into thinner layers and added until any one of 0.5, 1.0, or 2.0 is reached).

Joseph

On 20 September 2017 at 19:33, Saeran Vasanthakumar < notifications@github.com> wrote:

I see, so the .m file method for calculating soil thickness is the one we want to keep, because it maintains an assumed road construction depth.

In this part:

Furthermore, if you give people the option of making the ground thicker, it could cause the heat flow solver to fail because (much like EnergyPlus) it is really only meant to handle thicknesses less than a half-meter or so. So he just fixed the depth of the ground at a specific thickness.

Do you mean street depth here, not ground depth? Is UWG changing the ground depth at any point? In the code it looks like we are only fixing/changing the ground temp that is under the road construction, and road thickness:

This is the loop in the .m file:

        % For .m file, assume the soil depth is close to one of the ground
        % soil depth specified in EPW (0.5, 1.0, 2.0)
        for i = 1:n_soil
            if sum(road.layerThickness) <= depth(i)
                soilindex1 = i;
                break;
            end
        end

and here for the .xml file:

    % Define Road Element & buffer to match ground temperature depth
    urbanRoad = xmlUCM.urbanRoad;
    [roadMat, newthickness] = procMat(urbanRoad.materials,max_thickness,min_thickness);
    for i = 1:n_soil
        if sum(newthickness) <= depth(i)
            while(sum(newthickness) < depth(i))
                newthickness = [newthickness; max_thickness];
                roadMat = [roadMat soil];
            end
            soilindex1 = i;
            break;
        end

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chriswmackey/urbanWeatherGen/issues/16#issuecomment-331033959, or mute the thread https://github.com/notifications/unsubscribe-auth/ALUG7aMsNPTBF8kLoPvcYKynI217jLv2ks5skcrngaJpZM4PdS1Q .

[chriswmackey]

@hansukyang , Thank you very much for the response and it helps a lot. It seems that the method was much more complex than I realized but it generally sounds good to me.

[hansukyang]

Glad it helps. Please feel free to ping me about any questions as you guys move forward.

On 24 September 2017 at 07:31, Chris Mackey notifications@github.com wrote:

@hansukyang https://github.com/hansukyang , Thank you very much for the response and it helps a lot. It seems that the method was much more complex than I realized but it generally sounds good to me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chriswmackey/urbanWeatherGen/issues/16#issuecomment-331713834, or mute the thread https://github.com/notifications/unsubscribe-auth/ALUG7ZIlxn53tc3AGZ1b7oKW1pJSzR4hks5slmfMgaJpZM4PdS1Q .

[saeranv]

Thanks @hansukyang for the overview. It's very clear, but once I start getting deeper into the road and ground modeling I might be revisiting this issue, and will ask for further clarifications as needed.

[saeranv]

@hansukyang @chriswmackey

I'm in the process of coding the road layer thickness & ground temp/depth section and need to clarify two things:

First, is the correct method (as described in @hansukyang post above) for setting boundary soil temperature contained in the .xml file input procedure and not the the procedure outlined in the .m input section?

For the .m input method, we just take the first ground temp depth that is greater then the total road thickness, and don't modify the road layer thickness at all:

        % For .m file, assume the soil depth is close to one of the ground
        % soil depth specified in EPW (0.5, 1.0, 2.0)
        for i = 1:n_soil
            if sum(road.layerThickness) <= depth(i)
                soilindex1 = i;
                break;
            end
        end

Whereas for the .xml input, we take the first ground temp depth that is greater then the total road thickness, and then also add additional road thicknesses, and road material to match the ground temp depth:

        % Define Road Element & buffer to match ground temperature depth
        urbanRoad = xmlUCM.urbanRoad;
        [roadMat, newthickness] = procMat(urbanRoad.materials,max_thickness,min_thickness);
        for i = 1:n_soil
            if sum(newthickness) <= depth(i)
                while(sum(newthickness)<depth(i))
                    newthickness = [newthickness; max_thickness];
                    roadMat = [roadMat soil];
                end
                soilindex1 = i;
                break;
            end
        end
        road = Element(urbanRoad.albedo,urbanRoad.emissivity,newthickness,roadMat,...
            urbanRoad.vegetationCoverage,urbanRoad.initialTemperature + 273.15,...
            urbanRoad.inclination);

Of the two input methods, the only input procedure that divides, and adds the road thicknesses as @hansukyang was describing in his previous post is the .xml input. The road layer thickness method used for the .m file in contrast seems less accurate. Specifically, if the total road depth (i.e 0.6m) is slightly greater then the lowest ground temp (0.5m), it'll set the soil temperature at the 2m depth. rather then the 0.5m depth that is closer. So adding it via the .xml input seems to be right way.

Secondly, If we assume the .xml input is the correct procedure, doesn't this mean that if initial road depth is set slightly higher then the initial ground depth (i.e at 0.6m), the .xml input method will keep adding asphalt until it hits 2m? A 2m road depth seems way too thick and would produce inaccurate surface flux calculations down the line. To avoid this, should we be removing the road depth parameter we currently have in the initialize.uwg to avoid getting huge massive road depths?

I hope that is clear. Let me know if further elaboration is needed.

S

[hansukyang]

Hi Saeran,

Good observation. Again, my apology for the sloppiness of the code - I think it's making the translation work harder than it should have been.

For the .m part, I can't remember why I had assumed that the input depth will be close to one of the values in the EPW, but you're correct that 0.6m depth would peg it to ground temperature at 2.0m if this is the next one. I think I had used 0.5m for all the simulations and thought that this probably shouldn't change. For adding layers until it hits the next depth level (say 2.0m), it shouldn't affect the surface temperature variation, since the point of making thinner layers (e.g. at 0.05m) was to allow this variation.

To elaborate a little more on my previous email, the road thickness is also hard-coded here https://github.com/hansukyang/UWG_Matlab/blob/master/UWG.m#L220 to be 0.5m (and the layer thickness to be 0.05m) for the Excel input file section, which I believe is an error. I had hard-coded it to 0.5m after talking to Les and with the impression that very few building folks were familiar enough to want to adjust this but I think I added the parameter option it back in to the Excel input file without removing the relevant hard-coded section.

At the end of the day, the procedure for the .xml input should be the correct one. Let me know if this clarifies it. Thanks!

Joseph

On 15 October 2017 at 17:36, Saeran Vasanthakumar notifications@github.com wrote:

@hansukyang https://github.com/hansukyang @chriswmackey https://github.com/chriswmackey

I'm in the process of coding the road layer thickness & ground temp/depth section https://github.com/saeranv/UWG_Python/blob/master/UWG/UWG.py#L361 and need to clarify two things:

First, is the correct method (as described in @hansukyang https://github.com/hansukyang post above) for setting boundary soil temperature contained in the .xml file input procedure and not the the procedure outlined in the .m input section?

For the .m input method, we just take the first ground temp depth that is greater then the total road thickness, and don't modify the road layer thickness at all:

% For .m file, assume the soil depth is close to one of the ground % soil depth specified in EPW (0.5, 1.0, 2.0) for i = 1:n_soil if sum(road.layerThickness) <= depth(i) soilindex1 = i; break; end end

Whereas for the .xml input, we take the first ground temp depth that is greater then the total road thickness, and then also add additional road thicknesses, and road material to match the ground temp depth:

% Define Road Element & buffer to match ground temperature depth urbanRoad = xmlUCM.urbanRoad; [roadMat, newthickness] = procMat(urbanRoad.materials,max_thickness,min_thickness); for i = 1:n_soil if sum(newthickness) <= depth(i) while(sum(newthickness)<depth(i)) newthickness = [newthickness; max_thickness]; roadMat = [roadMat soil]; end soilindex1 = i; break; end end road = Element(urbanRoad.albedo,urbanRoad.emissivity,newthickness,roadMat,... urbanRoad.vegetationCoverage,urbanRoad.initialTemperature + 273.15,urbanRoad.inclination);

Of the two input methods, the only input procedure that divides, and adds the road thicknesses as @hansukyang https://github.com/hansukyang was describing is the .xml input. The road layer thickness method used for the .m procedure seems less accurate. Specifically, if the total road depth (i.e 0.6m) is slightly greater then the lowest ground temp (0.5m), it'll set the soil temperature at the 2m depth. rather then the 0.5m depth that is closer. So adding it via the .xml input seems to be right way.

Secondly, If we assume the .xml input is the correct procedure, doesn't this mean that if initial road depth is set slightly higher then the initial ground depth (i.e at 0.6m), the .xml input method will keep adding asphalt until it hits 2m? Isn't that road depth way too thick and produce inaccurate surface flux calculations? Should we be removing the road depth parameter we currently have in the initialize.uwg https://github.com/saeranv/UWG_Python/blob/master/resources/initialize.uwg to avoid this scenario?

I hope that is clear. Let me know if further elaboration is needed.

S

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chriswmackey/urbanWeatherGen/issues/16#issuecomment-336753962, or mute the thread https://github.com/notifications/unsubscribe-auth/ALUG7QmZWuBBuuwqzEBg7v3fM76voNQEks5ssqUngaJpZM4PdS1Q .

[saeranv]

Thanks for the detailed explaination @hansukyang . Sorry for the late response here, I was travelling around for a bit.

Anyway, the way you're cutting the road into thin slices to model the 1D heat transfer through the road makes perfect sense. The thick roads shouldn't be a problem in terms of surface temp - although, as the road gets thicker there's more wasteful computation of heat transfer for road depths that will essentially be at equilibrium with the ground temperature ( a work colleague of mine pointed this out to me).

With that in mind, I'll use the .xml procedure for dividing and adding up road layers, and will keep the exposed d_road input parameter in the initalize.uwg. And finally, we'll make sure to advise the users to keep the road depths at a reasonable depth i.e 0.5 m to avoid any unnecessary heat transfer computation for every slice.

Thanks again for your detailed, and prompt clarification!

[hansukyang]

Glad to be of help! Feel free to reach out anytime.

Joseph

On 26 October 2017 at 21:10, Saeran Vasanthakumar notifications@github.com wrote:

Thanks for the detailed explaination @hansukyang https://github.com/hansukyang . Sorry for the late response here, I was travelling around for a bit.

Anyway, the way you're cutting the road into thin slices to model the 1D heat transfer through the road makes perfect sense. The thick roads shouldn't be a problem in terms of surface temp - although, as the road gets thicker there's more wasteful computation of heat transfer for road depths that will essentially be at equilibrium with the ground temperature ( a work colleague of mine pointed this out to me).

With that in mind, I'll use the .xml procedure for dividing and adding up road layers, and will keep the exposed d_road input parameter in the initalize.uwg. And finally, we'll make sure to advise the users to keep the road depths at a reasonable depth i.e 0.5 m to avoid any unnecessary heat transfer computation for every slice.

Thanks again for your detailed, and prompt clarification!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chriswmackey/urbanWeatherGen/issues/16#issuecomment-339867321, or mute the thread https://github.com/notifications/unsubscribe-auth/ALUG7RvhJa0NsTpaYeDpdmK6uqCglMvMks5swVeugaJpZM4PdS1Q .

[saeranv]

@chriswmackey @hansukyang, the latest PR includes the xml method of slicing/adding road materials for the read_inputs method.

This issue has been resolved so I'll close it. Thanks for all your help!

S

[hansukyang]

Good to hear. Thanks!

On 11 November 2017 at 17:30, Saeran Vasanthakumar <notifications@github.com

wrote:

Closed #16 https://github.com/chriswmackey/urbanWeatherGen/issues/16.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chriswmackey/urbanWeatherGen/issues/16#event-1337428196, or mute the thread https://github.com/notifications/unsubscribe-auth/ALUG7XfdgVgYwi57TQ5yDTEO5hO5XSsEks5s1koygaJpZM4PdS1Q .

[chriswmackey]

Looks great @saeranv . Thanks!