-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UWG error if soil depth < 3 in EPW file. #96
Comments
Hi Saeran,
Yep, this works but a note of caveat that this was a bit of a hack, and
one that should be updated.
Basically, if ground temperature is not provided, it was set to be equal
to the annual average of air temperature in the original UWG. I found
this temperature to be somewhat high (maybe it should have been at least
the average of wet-bulb temperature?) for places like Singapore, so had
added in -10C adjustment. In my update, I think I remember using the
water temperature to calculate energy used for water heating so this was
somewhat important (and wanted to be conservative) but this assumption
doesn't quite work for seasonal places like Boston where you can
actually feel the difference in tap water temperature during summer and
winter - however, in these cases the EPW file included ground
temperature so it never became an issue.
Anyhow... if ground temperature is provided but less than 3, I think we
can either take water temperature at different depth, or also implement
thermal diffusion routine to calculate it. The second option is a bit
more involved but one where it might be preferable in the longer term,
especially for users that create AMY file, since I understand that AMY
files tend to just copy the ground temperature from TMY and may lead to
error.
Let me know if this makes sense. I will also try to get back to you on
the earlier question but my memory is a bit more vague on that one... :(
Joseph
…On 12/5/18 3:01 AM, Saeran Vasanthakumar wrote:
@hansukyang <https://github.com/hansukyang>,
One of our users ran into trouble with an epw file that provided
ground temperatures for only one soil depth, and not three as we have
tested in the past.
Specifically, the monthly self.forc.waterTemp variable is taken from
the 3rd soil depth in all cases, unless the number of soil depths is
equal to zero (this is how the original matlab code treats this).
|if self.is_near_zero(self.nSoil): # for BUBBLE/CAPITOUL/Singapore
only self.forc.deepTemp =
sum(self.forcIP.temp)/float(len(self.forcIP.temp)) self.forc.waterTemp
= sum( self.forcIP.temp)/float(len(self.forcIP.temp)) - 10. # for
BUBBLE/CAPITOUL/Singapore only else: # soil temperature by depth, by
month self.forc.deepTemp =
self.Tsoil[self.soilindex1][self.simTime.month-1] self.forc.waterTemp
= self.Tsoil[2][self.simTime.month-1] |
I changed the code so that the if condition is now |if self.nSoil < 3:
|, that is, if any soil depth less then three is provided, the uwg
will default to taking the self.forc.waterTemp, and self.forc.deepTemp
using the method it uses for when no soil depth is provided in the uwg.
My changes are here:
https://github.com/ladybug-tools/uwg/pull/95/files#diff-a226d4381c852ce81325ea5b7180fdc2R772
Let me know if this sounds okay, and if not, I'll revert the code.
Thank you,
Saeran
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#96>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALUG7cqswCbSjcUqEuf6lI8cOlN9JrQTks5u1sZ4gaJpZM4ZBTAQ>.
|
I see, in that case, I agree we should try and calculate the water temperature via a thermal diffusion routine. I won't be the person to write it, but can ask a work colleague to take a look at it, and will run it by you. As for the treeSensHeat question, I understand it's tricky! The heat contribution of the trees and vegetation are split across a couple of different methods (SolarCalcs, urbflux, infracalcs, element.surfFlux) so it's understandable it's harder to pin down. It's not an urgent problem, so we can let it be if we need to. By the way, that question came out of a user's questions about the vegetation/tree participation in the UWG heat balance from here: https://discourse.ladybug.tools/t/general-questions-about-the-input-parameters/4358 and inexplicable behaviour of trees/vegetation here: https://discourse.ladybug.tools/t/urban-heat-island-in-an-all-green-scenario/3497/6 Feel free to jump into those discussions and answer directly. The latter question, regarding tree obstruction of IR exchange, deserves a git issue of it's own I think, since after reviewing the code, and reading Bruno's original chapter on the objective of the vegetation in UWG, it still doesn't make sense to me why the tree fraction is not part of the IR exchange, and conversely, why the direct and diffuse solar received by the ground isn't blocked by trees. Again, not urgent issues, but worth documenting to see if I'm just missing something obvious here. S |
Sounds good - there are simple Python routines for solving 1D thermal
diffusion problems so it should be relatively straightforward. Thanks for
the link to the discussion forum - will take a look to see if there's
anything I can contribute.
Joseph
…On Thu, 6 Dec 2018 at 14:13, Saeran Vasanthakumar ***@***.***> wrote:
@hansukyang <https://github.com/hansukyang>
I see, in that case, I agree we should try and calculate the water
temperature via a thermal diffusion routine. I won't be the person to write
it, but can ask a work colleague to take a look at it, and will run it by
you.
As for the treeSensHeat question, I understand it's tricky! The heat
contribution of the trees and vegetation are split across a couple of
different methods (SolarCalcs, urbflux, infracalcs, element.surfFlux) so
it's understandable it's harder to pin down. It's not an urgent problem, so
we can let it be if we need to.
By the way, that question came out of a user's questions about the
vegetation/tree participation in the UWG heat balance from here:
https://discourse.ladybug.tools/t/general-questions-about-the-input-parameters/4358
and inexplicable behaviour of trees/vegetation here:
https://discourse.ladybug.tools/t/urban-heat-island-in-an-all-green-scenario/3497/6
Feel free to jump into those discussions and answer directly.
The latter question, regarding tree obstruction of IR exchange, deserves a
git issue of it's own I think, since after reviewing the code, and reading
Bruno's original chapter on the objective of the vegetation in UWG, it
still doesn't make sense to me why the tree fraction is not part of the IR
exchange, and conversely, why the direct and diffuse solar received by the
ground isn't blocked by trees. Again, not urgent issues, but worth
documenting to see if I'm just missing something obvious here.
S
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#96 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALUG7RuqJx9PGf0RPAGApeCqphmXn6doks5u2LWSgaJpZM4ZBTAQ>
.
|
Update: I actually have more on my plate then expected so am adding a "help wanted" tag to this issue. If anyone wants to tackle this, go for it! |
I added soil temperature to the weather API for cases such as this (reference). Not sure how that would help in this usage case though but is this something that gets raised often? |
I would estimate the issue is raised rarely, since we had the UWG released for a while before it finally threw the error. Does your weather API calculate the soil temperatures at different depths using the thermal diffusion routine? |
Soil temperatures at various depths is already calculated by the numerical weather models (both ERA5 and GFS) that the data is sourced from. This would again be a much more sophisticated version of the thermal diffusion routine since it would take into account soil type, soil moisture content, water run-off etc. |
If the reanalysis data is calculating the soil temperatures more accurately then the calculation we were discussing more, then should we just recommend users use reanalysis data if they care about modeling the ground and water temperature accurately in scenarios with missing soil depth temperatures? Why increase the code complexity with a suboptimal calculation if a more accurate alternative exists? I can add a warning when soil temps are less then 3, with an explanation that we are using the average air temp minus 10, but that we recommend weather files with at least 3(?) soil depths for more accurate ground and water temperatures. |
Yeah that would make sense. This would be especially the case if they are trying to use AMY. |
@hansukyang,
One of our users ran into trouble with an epw file that provided ground temperatures for only one soil depth, and not three as we have tested in the past.
Specifically, the monthly self.forc.waterTemp variable is taken from the 3rd soil depth in all cases, unless the number of soil depths is equal to zero (this is how the original matlab code treats this).
I changed the code so that the if condition is now
if self.nSoil < 3:
, that is, if any soil depth less then three is provided, the uwg will default to taking the self.forc.waterTemp, and self.forc.deepTemp using the method it uses for when no soil depth is provided in the uwg.My changes are here: https://github.com/ladybug-tools/uwg/pull/95/files#diff-a226d4381c852ce81325ea5b7180fdc2R772
Let me know if this sounds okay, and if not, I'll revert the code.
Thank you,
Saeran
The text was updated successfully, but these errors were encountered: