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

[saeranv]

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

[hansukyang]

Hi Saeran,

Sorry for the late reply. It's a correct observation and this was done when I removed the latent heat calculation from the UWG, since it was very difficult to validate this part of the calculation (along with evapotranspiration from vegetation). From my recent observations on electricity grid demand modelling, it seems that accounting for rain/snow is very difficult to do, somewhat corroborating this removal as well. In any case, instead of deleting this part of the code completely, I had just nullified it in case this can be revisited in UWG. The occurrence of rain or snow is typically low enough that this didn't affect the overall result even for relatively wet climate like Singapore but perhaps it should be clarified more.

Cc'ing Jiachen and Les, who might have more information based on the latest model.

Cheers, Joseph

On 8 January 2018 at 11:18, Saeran Vasanthakumar notifications@github.com wrote:

Hey @chriswmackey https://github.com/chriswmackey & @hansukyang https://github.com/hansukyang,

There seems to be an unused block of code in the element.SurfFlux method https://github.com/hansukyang/UWG_Matlab/blob/master/Element.m#L53 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.aeroCondparameter.colburndens(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 = egparameter.waterDensparameter.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 https://github.com/hansukyang/UWG_Matlab/search?utf8=%E2%9C%93&q=waterStorage&type=. 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 https://github.com/hansukyang/UWG_Matlab/blob/master/UWG.m#L279 in the UWG.m file. Or are we deliberating omitting this calculation?

-S

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

[saeranv]

Thanks @hansukyang, that makes sense. I see now that this is part of the latent heat calculation removal you mentioned earlier.

I imagine that another contributing factor to the difficulty of modeling latent heat is that EPW files have pretty poor quality precipitation data (i.e the Singapore EPW file doesn't contain any data for precipitation). I believe @chriswmackey is intending to include higher-quality precipitation data sources from NASA in Dragonfly https://github.com/mostaphaRoudsari/ladybug/issues/86 which I think would be a better source for the forc.precip parameter in the weather source, at some point in the future.

In the meantime, I'll add a comment to the code with your explanation, I think the broader argument you're making about latent heat modeling would be a useful reference in the code documentation.

-S

[hansukyang]

Sounds good, and thanks for the insight on EPW. I didn't even realize that Singapore EPW didn't contain any precipitation data! In any case, this information is great to know going forward.

I'm not sure if you guys have seen this: https://power.larc.nasa.gov/new/, but I think this will be a super useful set of information for building energy simulation. While the current data is only available on daily basis, I'm told that they will also host EPW format in the future.

Cheers, Joseph

On 14 January 2018 at 15:17, Saeran Vasanthakumar notifications@github.com wrote:

Thanks @hansukyang https://github.com/hansukyang, that makes sense. I see now that this is part of the latent heat calculation removal you mentioned earlier.

I imagine that another contributing factor to the difficulty of modeling latent heat is that EPW files have pretty poor quality precipitation data (i.e the Singapore EPW file doesn't contain any data for precipitation). I believe @chriswmackey https://github.com/chriswmackey is intending to include higher-quality precipitation data sources from NASA in Dragonfly mostaphaRoudsari/ladybug#86 https://github.com/mostaphaRoudsari/ladybug/issues/86 which I think would be a better source for the forc.precip parameter in the weather source, at some point in the future.

In the meantime, I'll add a comment to the code with your explanation, I think the broader argument you're making about latent heat modeling would be a useful reference in the code documentation.

-S

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

[chriswmackey]

This is a very interesting discussion and I can corroborate the fact that, even when precipitation data is in the epw, it's almost never accurate. Hourly liquid precipitation depth recorded with rain gauges (the most common form of measurement used with weather stations) is not very accurate because water sticks to the sides of the gauge, wind blows the water away from/out of the gauge, and these gauges don't work well in snow conditions. Our most accurate understandings of rainfall come from observations of larger catchment areas. There have been attempts to correlate these accurate understandings with cloud cover seen in weather satellites and this is where our most accurate estimations of hourly precipitation data are likely to come from. Specifically the GPM database (https://www.nasa.gov/mission_pages/GPM/main/index.html) has some of the best measurements to date. The dataset is younger than the data in most epws so it will be some time before we start seeing epw data that is informed by the database.

In the meantime, I wanted to build out a connection to the database at in the near future. I'm not sure yet how this might influence the accounting of rain in the UWG since, as I mentioned, this data likely won't be correlated with epws. However, leaving the ability to account for rain in the UWG there but commented out sounds like a good route for now.

[saeranv]

Took a long time, but I finally documented the instances of where and why we're not calculating latent heat exchange in the code with the latest PR #43. Thank guys.

I think we can move the discussion of future development of better precipitation/climatic data to a new issue as an enhancement when we are ready to pursue it.