the "hump" on the comfortPolygon in the adpative comfort chart

There is a "hump" on the comforPolygon in the adaptive comfort chart component:

May I ask what this part of the polygon represents? The adaptive comfort chart in ASHARE2013 doesn't show such "hump"...

Thank you very much!

Attachments:

thermal_comfort_calc_v001.gh, 417 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Grasshope on March 16, 2016 at 1:35am

... OK, I may have found the explanation:

On page 13 of ASHARE 55-2013, paragraph 5.4.2.4, it is indicated that if operative temperature is above 25 degrees, the upper limit of acceptable temperature is allowed to be increased, depending on the air speed as specified in Table 5.4.2.4, which can be as high as 2.2 degree.

So, I assume the height of the "hump" is about 2.2 degrees from the upper acceptability limit (80% or 90%).

Appreciate your advice if the understanding here is not correct.

Permalink Reply by Chris Mackey on March 16, 2016 at 8:45pm

Grasshope,

Your citation from ASHRAE 55 is correct. The "hump" will go away if you input a windSpeed of 0 into the adaptive chart component. Not many people know about the provision for increased air speed in the Adaptive model but it ends up being very useful for design.

Also, I should note that both ASHRAE and the European adaptive model have this provision for increased air speed. For another reference regarding the effect of increased airspeed in both US/EU adaptive models, you can check out the "Adaptive Method" of the CBE Comfort Tool:

http://comfort.cbe.berkeley.edu/

-Chris

Permalink Reply by Mostapha Sadeghipour Roudsari on March 19, 2016 at 9:01am

Chris,

I should probably add this to github but I wanted to also have Grasshop's input on this.

Do you think that we should change the "Desired indoor operative temperature" to "Indoor operative temperature"? As far as I understand the desired temperature is the area inside the curve and not the axis values itself.

Mostapha

Permalink Reply by Chris Mackey on March 19, 2016 at 3:23pm

Mostapha,

I agree. For a while, I debated with myself what the axis label should be and, for the plotting of the polygon, it is "desired" but, for everything else plotted on the chart, it might not be. I have changed it here:

https://github.com/mostaphaRoudsari/ladybug/commit/87554cd3c1906d4a...

-Chris

Attachments:

Adaptive Comfort Chart.gh, 565 KB

Permalink Reply by Grasshope on March 21, 2016 at 8:39am

Dear Chris and Mostapha,

Thanks for your clarification!

Yes, I agree with you that using "Indoor operative temperature" for the Y axis of the adaptive comfort chart might be less confusing, and plus it is consistent with what is presented in the ASHRAE standard.

Users should be able to use the outputs of this component to filter out those measurements within or outside the acceptable limits.

Speaking of the outputs of this component, I got the following issue which I'd like to have your advice:

As shown in the image, the output of the "comfortableOrNot" node has 2 branches and 17534 values, which is strange because the input epw file has only 8760 hourly data (8767 including the headers).

Sth must have caused the duplication, and I hope you can kindly point out what I missed here.

Thank you!

Attachments:

thermal_comfort_calc_v002.gh, 459 KB

Permalink Reply by Grasshope on March 21, 2016 at 9:00am

... sorry to bother, but the position of the output point of the following input combinations doesn't seem to be right, and it is not consistent with the outcome of the CBE tool for the same inputs:

Hope you can advise what I missed here:

Attachments:

thermal_comfort_calc_v003.gh, 467 KB

Permalink Reply by Chris Mackey on March 21, 2016 at 7:42pm

Grasshope,

I will check the duplication issue once I get more time to sit down and check your file.

Thank you so much for posting about the misplaced point in relation to the CBE tool. It was a bug in the chart that only affected cases when you connect up single values to airTemperature, radTemperature and prevailTemp. It was accidentally setting the prevailing temperature as the y-coordinate of the point and the operative temperature as the x-coordinate. All other uses of the chart were good so that might be why I didn't notice it until you pointed it out here.

I fixed it in the attached file.

Thanks, as always, for your vigilant pursuing of bugs.

-Chris

Attachments:

AdaptComfFixed.gh, 382 KB

Permalink Reply by Abraham Yezioro on March 22, 2016 at 8:53am

Hi Chris,

One small bug: Setting the wind speed to 1.2 gives the following error:

1. Creating an outline of one of the comfort or strategy curves failed. Component will return a solid brep.

1.19/1.21 are fine. 1.2 doesn't.

Thanks,

-A.

Permalink Reply by Chris Mackey on March 22, 2016 at 8:56pm

Great Bug-Catchers Abraham and Grasshope!

Thank you for your attention on this component. Thanks to your efforts, I feel that we are really weeding out a lot of the small errors I made when I originally put the component together a few months ago.

Abraham, the case of 1.2 failing was because of a bug where I simply put "< 1.2" in the code instead of "<=1.2". The error was specifically happening with 1.2 because that is the wind speed threshold at which the "hump" of the ASHRAE adaptive comfort polygon grows. It is perhaps easier to see this threshold in the inputs of the CBE Adaptive comfort chart:

I fixed the bug in the attached file and on the github.

Grasshope, to address why you are getting branched data and the 2 comfort polygons, it is because you have connected up the EPW windSpeed to the component. Usually, if you connect up multiple values for windSpeed_, the component will produce a comfort polygon for each wind speed. However, I built a mechanism into the component that stops it from generating 8760 comfort polygons (one polygon for each hour) if you connect up full EPW data. 8760 comfort polygons takes almost a minute to generate and so I figured that this is probably not what people want to do most of the time. Instead, the component just generates one polygon for the minimum wind speed and another for the maximum wind speed (to show you the range). The branched data that you get out of the component are values for each polygon (2 branches for two polygons). If you connect up the data to the 3D chart, this might make things clearer:

One polygon is for 0 wind speed and the other is for the maximum EPW wind speed.

I am interested in hearing your thoughts on my way of dealing with this since I am thinking of implementing something similar on psychrometric chart. I realized that a lot of people were crashing the psych chart by connecting up the EPW wind speed, which currently tells the component to generate 8760 comfort polygons.

Thanks, as always, for all of your help,

-Chris

Attachments:

thermal_comfort_calc_v002_CWM.gh, 473 KB

Permalink Reply by Abraham Yezioro on March 22, 2016 at 11:29pm

Thanks Chris.

Yes i saw the 1.2 at the CBE and that's why i reported.

I'm thinking about your question regarding min/max wind speed. On one side, as you said, it speeds the calculation time significantly. On the other it will be interesting to calculate how many points felt in the extra comfort area but don't have the wind speed to really be in comfort. Dilemma!!

But if the options are a crashing component/exaggerated calculation time, i'm for this min/max wind assumption. If it is only running time, maybe a flag input saying "Take all wind speeds" or "Take min/max values" can be fine. But if crashing is a real situation ... then simplify.

-A.

Permalink Reply by Chris Mackey on March 23, 2016 at 9:15am

Abraham,

Thank you for your thoughts. I should also mention the alternatives that I am considering:

1) The component can sense whether the windSpeed data is aligned with the _dryBulbTemperature and _prevailTemperature and, if so, I just output 1 branch of data using the wind speed at each hour. It sounds like you would advocate for this and, as I am thinking about it more, this makes sense to me too.

2) Instead of outputting 2 polygons, I could just output 1 that represents the mean wind speed for the whole year. I am not sure if this is better.

3) Instead of outputting 2 comfort polygons for the min and max windSpeed, I could run some statistical analysis on the data and output two polygons for 1 upper and lower standard deviation. This might be more representative of the range over the year but, again, I am not sure.

Any thoughts on this or suggestion of other options is much appreciated.

-Chris

Permalink Reply by Abraham Yezioro on March 23, 2016 at 2:13pm

Hi Chris,

If the goal of the polygon(s) is only the graphics (for showing) i believe the 2 polygons are fine (min and max over the analysis period).

The question is regarding the calculation of comfort. How it is done and/or how it should be done. The right way is point by point with the respective wind speed. What i understood is that this option can crash GH (isn't it? Or it happens just because it shows 8760 polygons?). If so the right way is not an option.

I'm thinking: There are 4 polygons overall, right (0, 0.6, 0.9, 1.2 m/s). So what if, according to the wind speed you take one of those polygons for the calculation, and for the graphic output the 2, min and max?

As for the options you mention, 1 is the one that "makes sense".

Op. 2 (average year), really DON'T.

Op.3 can be but didn't understand how it works for the calculation.

Makes sense?

-A.