Problem displaying annual indoor comfort metrics

Replies to This Discussion

Permalink Reply by Theodoros Galanos on February 18, 2015 at 11:59pm

I am now getting the old "calculation has been terminated by the user" error.

I am using your example to run it.

Kind regards,

Theodore.

Permalink Reply by Chris Mackey on February 20, 2015 at 7:21pm

Hi Theodore and Abraham,

Thank you guys for the discussion.  It is a good reminder that I should make a tutorial video soon that explains what is going on behind the scenes soon.

First, to answer Abrahams's question about how shades are accounted for in the simulation/thermal map and Theodore's thought that just accounting for shades in the E+ run was sufficient. I think that it may be clearest to explain what is going on with this infographic:

As the graphic shows, the thermal maps are made from 4 key types of inputs.  The radiant temperature map is formed through a consideration of both the temperature of the surfaces surrounding the occupants and the direct solar radiation that might fall onto the occupants through un-shaded windows.  The first surface temperature effect is easily computable from your Energy simulation results and the HBZone geometry.  However, the second is calculated by seeing how sun vectors pass through the windows of the zones and uses the SolarCal method of the CBE team (http://escholarship.org/uc/item/89m1h2dg) to compute an MRT delta resulting from solar radiation.  This delta is then added to the initial values computed through surface temperature view factor.  When you do not connect up your shading brep geometry, internal furniture breps, or outdoor context geometry that might block sun to the additionalShading input, the thermal map will assume that sun can pass unobstructed through the window or through indoor furniture to fall onto occupants.  It is important to stress that the EnergyPlus simulation does not count for blind geometry or internal furniture as actual geometry.  Just as numerical abstractions of surface area and material properties.  So we need you to plug in the actual geometry of these things when we compute the MRT delta resulting from sun falling directly onto people.

Next, to clear up the definition of window transmissivity.  The important thing to clarify here is that, whether it refers to the tranmittance of glass or to the amount of sun coming through a fine screen of blinds, the value is multiplied by the radiation falling on the occupant and thus has a direct correlation to the MRT Delta from sun falling on occupants.  So, if you set transmissivity to zero, the sun falling on the occupants will not be considered in the calculation and, if you set the transmissivity to 1, the assumption is that there is no window (or the window glass is 100% clear).  So, Abraham, your definition of it as a coefficient is appropriate.

Normally, I would just recommend that you leave this value at the default 0.7, which corresponds to the transmittance of the default glass material in Honeybee.  However, there are 4 cases in which you might consider changing it:

1) You are not using the default Honeybee glazing material, in which case, you should change the transmissivity to be equal to this new value.

2) You have a lot of really small blind/shade geometries and you do not want the view factor component to take several minutes to trace sun vectors through the detailed shade geometry and so you are ok with using just a simple abstraction instead of plugging shade breps into the additionaShading.  In this case, you might try to estimate the average percentage of radiation coming through the blind geometry (maybe with some simple Ladybug radiation studies or with your intuition about the amount of sun blocked by the shades).  You will then multiply this by the tranmissivity of your glass and this will be the value that you input to the component.

3) Your blinds for your Honeybee simulation are dynamic, in which case, plugging shade breps into additionalShading is not going to work because the component will assume that those shades are always there.  In this case, you should be plugging a list of 8760 values into the transmissivity that correspond to when the shades are pulled.  When the blinds are completely up, the value should be the tranmittance of your window and, when they are down, the value should be the window tranmittance multiplied by the fraction of light coming through the shades.

4) You have shades/blinds but they are transparent or are not completely opaque.  The additionalShading_ input assumes that all shade geometry is opaque and so you cannot use it to account for such shades.  Accordingly, you will need to account for it through the tranmissivity.

In the future, I may try to pull more information about blinds and glass properties off of the HBzones inside the view factor component but, for now and for the next few months, the above describes how it works.

Theodore, for curved geometry, I think that your safest bet is going to be planarizing the Rhino geometry before you turn it into a HBZone (so you just divide the curved surface into a few vertical planar panes of glass that approximate the curve well enough).  This is essentially what the runSimulation component does for you automatically (it meshes the geometry as you see here: https://www.youtube.com/watch?v=nMQ2Pau4q6c&index=12&list=P...).  If I were to figure out a way to incorporate shades in this automatic meshing workflow, your EnergyPlus simulation would take a very long time to run and I am not even sure if the result will be that accurate with the way E+ abstracts shades.  So I don't think that it's really worth it over just planarizing the geometry yourself.

Lastly, I won't be able to figure out the problem with your current run Theodore, unless I get the GH file from you.  Make sure that you are using all up-to-date components.

-Chris

Permalink Reply by Theodoros Galanos on February 20, 2015 at 7:47pm

Hey Chris,

Thanks for the detailed answer. I was going to ask if this was the way to account for automatic scheduling of blinds. Sounds cool.

As for the file, I completely switched to using your file which still gives me the error. I think I went over the components and made sure they are updated. I attach it for good measure.

Kind regards,

theodore.

Attachments:

• OfficeTower_CWM.gh, 699 KB

Permalink Reply by Chris Mackey on February 20, 2015 at 11:20pm

Theodore,

I just ran the GH file that you uploaded here for the whole year without a problem.  The annual simulation took 40 minutes on my computer, which is quite powerful now so be warned that this is a long process. It also maxed out my memory  few times so I would really encourage you to run it for short periods at a time.

Here's one of the result CSV files that you can use to plug into the "Read Indoor Comfort Result" component:

https://www.dropbox.com/s/r7zh3lvxfniywdj/unnamedOperativeTemp.csv?...

The issue seems to be specific to your system (or perhaps the weather file you are using).  Can you try running the attached GH file and tell me what the error message is?

-Chris

Attachments:

• OfficeTower_CWM_forTest.gh, 705 KB

Permalink Reply by Abraham Yezioro on February 20, 2015 at 8:46pm

Thanks Chris for the detailed explanation. Makes complete sense. Nice figure!!

I will consider changing the name of the transmissivityinput to, maybe, Coefficient of transmissivity, or something similar. Just to differentiate from the glass material property.

-A.

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