Nightlimit issue

[gianlucamaracchini]

Hi, I found this in UBLDef.py:

daylimit = parameter.dayThreshold # sunlight threshold for day (~150W/m^2) nightlimit = parameter.dayThreshold # sunlight threshold for night (~50W/m^2)

Maybe this is a typo (parameter.dayThreshold instead of parameter.nightThreshold for nightlimit).

Thanks

[saeranv]

(Reposting this, since I accidently used my work account to post the previous message).

@jmrk87

Yes, this looks like a bug, using the same threshold contradicts the next conditional statement below. The problem stems from the original UWG_Matlab:

            daylimit = parameter.dayThreshold;      % sunlight threshold for day (~150W/m^2)
            nightlimit = parameter.dayThreshold;    % sunlight threshold for night (~50W/m^2)
            sunlight = forc.dir+forc.dif;

            % If dir & dif light is greater than threshold, use day 
            if sunlight > daylimit && time <= noon ||...
                    sunlight > nightlimit && time > noon || obj.sensHeat > 150                

Ref: https://github.com/hansukyang/UWG_Matlab/blob/b96bc2a8458ce10990d9bdbea16c5cef17628c50/UBLDef.m#L66-L72

@hansukyang do you agree this is a bug, or are we missing something?

[hansukyang]

It's probably an error from me having played around with 'dayThreshold' and 'nightThreshold' being set to just a single value as I think I remember some of the UWG parameters did not really have noticeable effect.

FYI, I recently added 'boundary layer height' (https://docs.oikolab.com/#2-3-available-parameters) as an available weather parameter as this is available from NWP models. I haven't performed any analysis with it yet but was curious myself how it varies. Here in the plots below you can see how it varies over course of the day for Boston (rather than just two set values usually 50~80m for night and 700m for day in UWG) for a couple of years:

[saeranv]

Update: I made the change, but it's failing one unit test, so I need to figure out why that's happening before I can merge it. A lot of the unit tests were based on data from the UWGMatlab so a failing unit test is not alarming.

@hansukyang Interesting, I recall from Nakano's thesis sensitivity analysis the nighttime BL height was one of the parameters that had a "significant" impact on the UHI. Is there any way to also get data on the "h_ref" parameter - height at which potential temperature is uniform? "h_ref" It also had a big impact on the UHI.

[hansukyang]

Yes, BL has substantial impact on UWG because it essentially changes the control volume where urban air and rural air is mixed I believe.

I don't think 'h_ref' parameter is available on its own. On the other hand, do be cautious about looking too much into various atmospheric parameters on UWG such as BL or 'h_ref'. Recall that UWG is built on some shaky assumptions translating 3D phenomenon (atmospheric heat convection) into extremely simplified 1D process while being over-parameterized at the same time so it is very easy to tweak input parameters to get results that fit the data.

[saeranv]

@hansukyang Agreed, and thats why we advise everyone to not tweak the atmospheric parameters. But, according to Nakano's sensitivity study, the Night BL, and the inversion height parameters showed a "significant" impact on the resulting UHI and so relying solely on the default assumptions adds its own bias.

So wouldn't selected use of measured-cum-simulated/ERA5 data for atmospheric parameters improve the accuracy of the UWG simulation? Or would even that be out of scope or change underlying assumptions of the simplified 1D process for the atmospheric portion of the UWG?

[hansukyang]

I think that would be an interesting study. As you can see in the plots above, the boundary layer height varies considerably and the reservation that I have is that the definition of parameters such as 'boundary layer' as defined in UWG may be different than NWP datasets such as ERA5.

Feel free to download boundary layer variable from https://weatherdownloader.oikolab.com and play around (I think you should still have account to download this data). Inversion layer height is a bit tricky because temperature is given at various pressure heights (we don't have this yet but you can get it directly from Climate Data Store) and this value would have to be derived.