Outdoor comfort - Solar Adjusted MRT - Issue with contect

Replies to This Discussion

Permalink Reply by Chris Mackey on October 28, 2014 at 2:54pm

Hi Bernardo,

Thank you for reporting.  I just did a massive overhaul of this component this past weekend and I found the bug that you mentioned in this discussion.  The bug was essentially that the context was not being meshed correctly and it has since been fixed.  You can get the new component by syncing with the github or by using the component that is in the attached GH definition.

Also, I should note that a key new feature that has been added in this overhaul is the ability to run a much faster calculation using a method that was developed by the awesome comfort scientists over at the center for the built environment (http://escholarship.org/uc/item/89m1h2dg).  The new method gets you results that are very close to that of the full mannequin mesh but in about 1/50th of the time by extrapolating the mannequin geometry down to a set of 9 points and using some coefficients to compensate for the geometry of the human body.

Lasty, I put in options of 3 simplified mannequin meshes for the 3 different body positions (standing, sitting, and lying down).  This should allow you to run a faster version of the older method if you so desire.  They can be accessed by plugging integers 3,4 or 5 into the BodyPosture input.

Ultimately, the new fast methods are going to allow us to factor in direct solar radiation in the indoor temperature maps that I have been working on:

https://www.youtube.com/watch?v=__cRBh2DGMA&list=UUc6HWbF4UtdKd...

I will post a new tutorial video on the updated solar MRT adjustor and the indoor temperature maps once I finish developing the full workflow to make indoor comfort maps.

Permalink Reply by Chris Mackey on October 28, 2014 at 6:19pm

I forgot to attache the correct file.

Attachments:

• MRT Solar Temp AdjusterV2.gh, 678 KB

Permalink Reply by Berardo Matalucci on October 29, 2014 at 7:25am

Hey Chris,

Thank you very much for your message and thanks for fixing up the bug. I was aware of the CBE paper and their method is great.

I was wondering if you have ever encountered any discrepancies with other models. It seems that the CBE is tailored for indoor conditions, whereas other models are focused on outdoor (for example Rayman Model). 

http://www.mif.uni-freiburg.de/rayman/

http://www.mif.uni-freiburg.de/rayman/description.htm

I will dig more into that...

Cheers,

berardo

Permalink Reply by Chris Mackey on October 29, 2014 at 11:22am

Bernardo,

I have not delved too deeply into RayMan or done a results comparison from both models but, as I understand it, the underlying principle of the indoor and the outdoor MRT calculation is the same and should be applicable to both cases.  Both are trying to estimate the amount of solar radiation that falls on the human body and, in the case of RayMan, this seems to be fed into a human energy balance equation with terms for long wave radiation while, for the CBE Tool, they pull out just the terms of this equation that has to do with direct/diffuse solar radiation to give an MRT delta off of an an existing MRT from long wave radiation.

The rayMan method is nice for outdoor because you usually have no idea of the longwave radiation from outside surfaces but, for indoor, you usually have accurate MRT already from an energy simulation so all that you need is a delta.  As I understand it, this is the only major thing that makes the tool suited to indoor vs outdoor.  For using the Ladybug tool, I caution that, if you start having a lot of context surfaces in outdoor cases, it is really important to try to get an accurate starting longwave MRT instead of using the air temperature.  Ryaman seems to have ways of doing this long wave calculation and I think I will create some workflows in the future that use the outdoor surface temperature from E+ simulations to help with this.

In any case, with all of this taken together, the geometry and exact position of the human body usually ends up being very important to estimating an exact MRT delta for solar radiation and, as a designer or engineer, it can be very difficult to know this for your real-world case since all that the occupant has to do is tilt their chair.  This is one of the main reasons why I started this component with a mannequin that showed where the radiation was falling on the person so that everyone could be aware of the assumptions.  So, given this large uncertainty, I would take any of the results of a solar temperature estimator with a significant margin of error from the real-world case (maybe 10-20%) and just use it to get a sense of the order of magnitude change that the sun produces.  Both Rayman and, the CBE method, and the Ladybug component should all fall withing this margin of error and order of magnitude.

I hoe this was helpful,

-Chris

Permalink Reply by Reinier Zeldenrust on October 29, 2014 at 10:04am

Hi Chris,

Thanks for the update - the context seems to work now!

However, the body posture doesn't seem to work - only 1&2 as inputs work, the rest throws an error. 

Also, the window transmissivity doesn't change anything.

Finally, is there a way to get the MRT plotted on the mesh faces instead of the solar radiation?

Many thanks!

Permalink Reply by Chris Mackey on October 29, 2014 at 11:38am

Reiner,

Can you upload your GH file?  Both of these things are working fine on my system.  Here's the zero body posture, for example:

As for changing the solar radiation on the mannequin over to radiant temperature, there is a direct relationship between the ERF and the MRT but the ERF is the radiant field over the whole human body.  Still, think it should be possible to apply the same equations before computing an ERF over the whole body to give a radiant temperature for just one polygon at one hour.  However, once you start looking at longer analysis periods, this radiant temperature might not make so much sense.  I will give it a try at some point and see what comes out.

-Chris

Permalink Reply by Reinier Zeldenrust on October 30, 2014 at 7:17am

Hi Chris,  see upload. I've updated all the definitions to the latest version of ladybug / honeybee, so I don't know what's going wrong.

I understand the MRT isn't a sensible parameter for a longer analysis period but it would be quite useful for a point-in-time (peak) comfort study. Discomfort can arise from high radiant temperatures but also strong variations in radiant temperatures for different directions - which is what we're trying to study. I'd hoped this definition would help, but we're also exploring working with viewfactors and surface temperatures.. 

-Reinier

Attachments:

• AdjustedMRT_Error.gh, 410 KB

Permalink Reply by Chris Mackey on October 30, 2014 at 12:25pm

Reiner,

I could not replicate your error but I can think of 2 reasons why this is happening.  The first is that you were using a LB_LB that was all of the way back from August with a brand new component form October.  The second could be that, when I added in the new method this weekend and had certain inputs go blank, the component freaked out because it didn't know where these inputs are.  I just put in some extra checks that should prevent these situations from happening in the future.  Let me know if the attached file works.

You have won me over with the temperature asymmetry argument.  I am sure that the asymmetry is way out of the bounds of ASHRAE's acceptable limits and you should be able to see this.  Also, maybe there is a way that we could do an average radiant temperature over an analysis period in those cases.  I will try to get to this feature soon:

https://github.com/mostaphaRoudsari/ladybug/issues/97

-Chris

Attachments:

• AdjustedMRT_Error_CWM.gh, 364 KB

Permalink Reply by Reinier Zeldenrust on November 6, 2014 at 5:41am

Hi Chris,

For some reason it still wouldn't work with your example - when I set 0 as the body posture it says 'Solution exception:len() of unsized object'. 

Ok, I look forward to seeing the MRT output in the component! If you need me to test anything let me know - I know a bit of Python as well, so I could help out.

Cheers,

Reinier

Permalink Reply by Chris Mackey on November 6, 2014 at 9:40am

Hi Reiner,

I'm sorry for the difficulties that you are experiencing with this and thank you for being patient.  I have not been able to replicate the error on my system and I keep getting the results below:

Also, there seem to be at least two other users who have the new component working on their machines so it seems that the problem is specific to something on your system.  If you could post the full error that you are getting (with the lines of code), this will help me diagnose the problem.  It could be an issue with different versions of RhinoCommon that people have on their systems or maybe it's something related to the Radiance functions. Have you been able to run Ladybug radiation studies ok?

I will post here once the mannequin is colored with radiant temperature so that you know when it's ready.

-Chris

Permalink Reply by Abraham Yezioro on November 6, 2014 at 11:16am

Hi,

Just to make some service here :-)

I have the same error as Reiner's. Body position 0 is not working. The error says:

Runtime error (TypeErrorException): len() of unsized object
Traceback:
  line 2417, in text2srf, "<string>"
  line 2362, in createLegend, "<string>"
  line 704, in resultVisualization, "<string>"
  line 796, in main, "<string>"
  line 1537, in script

Something is wrong with the legend. I also noticed that in this case part of the legend is baked into Rhino kWh/m2 part).

I have R5 SR9.

Hope it helps to debug.

-A.

Permalink Reply by Chris Mackey on November 6, 2014 at 8:14pm

Ok, Guys.  I figured out what the issue is.  Like many of our issues where I can't initially replicate the error on my machine, this is an error that results from the Rhino model tolerance not being small enough.  Because of this and the fact that the standing person generates such small text in the legend, some generated text is smaller than the Rhino model tolerance and this causes the text2srf function to fail.

Thank you, Abraham, for giving me a detailed status of the problem.  The reason why you get some text baked into the Rhino scene is that the text2srf function actually works by writing the text into the model, grabbing the outline of the text, and then deleting the baked geometry.  We have to do this since GHPython offers no way to make interactive Rhino text objects and, when this function is interrupted as it was here, you get some text baked into your Rhino scene before it can be deleted.

So the original issue should be solved if you just decrease your model tolerance from 0.01 to 0.001.

I have made the component in the attached file a bit smarter so that it will sense when this tolerance is not correct and will not fail when your Rhino tolerance is so coarse.  However, I still really recommend that you keep a very fine tolerance if you are working with this component or else you will end up with text that looks like this:

I considered other methods like scaling the whole mannequin but it seems important to keep this component's mannequin at the correct anatomical scale of a human in the Rhino model.

Thanks again, guys for being patient and helping me diagnose the problem.  Mission accomplished!

-Chris

Attachments:

• SolarAdjustedMRT2.gh, 368 KB

• ‹ Previous
• 1
• 2
• Next ›
• Page