Incorporate mass balance for water vapor

[saeranv]

To consider: incorporating a mass balance for water vapor, referenced in A new model of urban cooling demand and heat island - application to vertical greenery systems (VGS) . This would allow for a better modeling of Vertical Greenery Systems on cooling demand of buildings and urban microclimate (rather then through the input of a 'latent fraction' variable in current UWG.

[saeranv]

Adding for reference: this conversation on the LB forums seems relevant: https://discourse.ladybug.tools/t/water-features-in-outdoor-thermal-comfort/3248, from @ocni-dtu

More info on that GPL catchement modeling framework over here: https://pypi.org/project/cmf/

[chriswmackey]

@ocni-dtu or @saeranv

If either of you are able to answer a few questions about what it would take to integrate the catchment modeling framework into the uwg, this would be really helpful:

1. Does the CMF model have any dependencies that we cannot access to from ironPython?
2. What type of calculation time increase might be associated with doing a moisture balance like this at every time step of the year?
3. Does the CMF model need detailed precipitation data to model vegetation correctly? Knowing that the precipitation in the EPW files is rarely accurate, I am just wondering if we need to expose access to better precipitation data before we aim to add this in.

[saeranv]

@ocni-dtu is definitely the expert here, so if you can answer these questions that would be great!

@chriswmackey has already provided a good background of the limitations of UWG's moisture balance here: https://discourse.ladybug.tools/t/outdoor-comfort-utci-microclimat-map-vegetation-limitations/3263/5, but let us know if you'd like to have more background on what UWG is doing.

Additionally, although I'm busy at work right now, once I get home I can look provide some more context about the specific inputs for the previous latent heat calculation in UWG that was disabled by Joseph.

[ocni-dtu]

Hey guys,
Yes, I some more background on UWG would be appreciated.

I hope answers your questions @chriswmackey :

Does the CMF model have any dependencies that we cannot access to from ironPython?

I'm not aware of that. The core of CMF is written in C++ and wrapped for Python with SWIG. However CMF has annouced that it is dropping Python 2 support (soon, but I don't remember the deadline). When that is said, I would always advice against spending too much time making stuff work with IronPython. That is why I have opened the question about Python 3 here and all the work I have done with Livestock is with that idea in mind. Anyways, I'm not sure if it is my place to say this, but I couldn't help myself, when you almost asked directly :)

What type of calculation time increase might be associated with doing a moisture balance like this at every time step of the year?

I have no idea, about the current speed of UWG, so I'm not sure how much it would affect the overall speed. However the C++ implementation of CMF makes it super fast, so I wouldn't worry about it. Especially if you are doing the rest of your calculations with IronPython, then your bottleneck will be there.

Does the CMF model need detailed precipitation data to model vegetation correctly? Knowing that the precipitation in the EPW files is rarely accurate, I am just wondering if we need to expose access to better precipitation data before we aim to add this in.

No CMF doesn't require that. My experience is that CMF doesn't really care. Precipitation is just a source of moisture into the system. When there is no available moisture in the ground, then the evapotranspiration stops. But this is not directly linked to Precipitation , the water could come from somewhere else.

[saeranv]

Okay so here's some context for UWG's moisture balance, which is based on my previous discussions from @hansukyang.

Overall, the current heat balance calculation for the UWG doesn't account for the moisture contribution from evapotranspiration from soil, vegetation, or from any bodies of water. In turn this effects the UWG's attempt to produce a UHI-based EPW because the calculated waste heat, or heat leakage from the buildings, and the surface flux from the urban canyon, aren't accounting for latent heat. So the objective here is to improve the moisture balance in the model by including a way to model these factors.

While the building energy model (BEM) does explicitly calculate the latent heat exchange (from infiltration, ventilation) between the urban canyon environment and interior setpoints, the canyon environment conditions aren't accounting for changing moisture conditions because of the latent heat limitations of the surface heat flux calculated.

The surface heat flux calcs for the canyon geometry (grounds, roofs) have a latent heat flux variable that accounts for moisture exchange from soil and vegetation respectively. The vegetation latent heat is represented by a latent heat fraction, but doesn't try and model any vegetative transpiration. The soil latent heat is based on the evaporation of some assumed thickness of water film of the soil and the precipitation data. This part is currently disabled, and so the soil latent heat is always = 0.

With better precipitation data, we can model the soil evaporation with the existing code, however, my understanding is that the reason @hansukyang disabled in the first place is because he was unsure about this calculation, and partly because the moisture from plants, and bodies of water aren't included so the humidity inputs for soil evaporation are already flawed.

So in summary, the vegetation, and soil conditions in our urban canyon aren't accounting for evapotranspiration, and the effect of large bodies of water aren't included in the model at all. It's still an open question to me of how this maps back to the CMF. I'll take a closer look at @ocni-dtu links, and get back with some questions of how it could potentially apply to the above framework.

[chriswmackey]

@saeranv and @oncni-tdu ,
Thanks for the summary.

It seems like any attempt to directly interface with CMF will be pretty challenging. If it's anything like the SWIG exported version of OpenStudio, I can already see how it might create difficulties.

Maybe there is a way of just borrowing some of the math of the library and use it for validation of something else that we write for the UWG.

@saeranv , as you are investigating this, I think the best way that I can help is by trying to find ways of itegrating precipitation data into EPWs. It seems the CMF doesn't need this per session but a useful application of it to the UWG would probably need this.

[saeranv]

@chriswmackey sounds good!

@ocni-dtu thanks for being patient while I look into this. I think for myself, I need to become a bit more familiar with how SWIG works, and also CMF. I'll likely post some more questions related to this when I get a chance to review some material on this.

[ocni-dtu]

Sure @saeranv. Feel free to ask questions