Thanks for reporting. The changing of the boundaries when you hook up legend parameters was intentional since I imagined users inputting their own boundaries that go along with their custom parameters. However, I can see now how this can be confusing so I have changed the default to not change the boundaries unless the user inputs custom boundaries into the legend parameters component.
I added a new input to the “Run Energy Simulation” component. You have to manually drag and drop the new version of this component onto the canvass (using the “Update Honeybee” component in this case will not work).
The shadeNetEffect is in kWh/m2 of shade and it gives you results on a cell-by-cell basis of each test shade.
The energySavedByShade is in kWh and is on a per-shade basis.
I have changed the description of these outputs to incorporate the units.
Note that you should take these values with a grain of salt as the energy savings are only computed by looking at the solar gains for the hours when you are cooling and they do not incorporate the effects of complex things such as thermal lag or accurately account for diffuse radiation. To understand exactly what your energy savings are from a given shade, you should take the Brep of the shade that you get from the Shade Creator, make it HBContext and re-run the energy simulation with the shade. Thus, the energy savings numbers that you get from the shade creator are more of a guideline, giving you a relative sense of the savings as shading size changes, rather than a final result.
Legends with Degree-Day/meters2 only happen when you use the “Comfort Shade Benefit Evaluator” rather than the “Energy Shade Benefit Evaluator.”
Chris: Can you confirm that the LB_ComfortShadeBenefitEvaluator works as you stated in the last point of you previous reply?
I’m connecting the output of the SunPath annual hourly data to the temperatures (as recommended in the hint), but the component gives an error (from the python editor):
Runtime error (ArgumentOutOfRangeException): Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index Traceback: line 105, in checkTheInputs, “<string>” line 805, in script
Sorry for the confusion with that. I had changed the internal method used by the component but not the input description. I have just changed it to the following, which correctly descibes what you should input:
_temperatures: A stream of 8760 temperature values representing temperature at each hour of the year that will be used to evaluate shade benefit. This can be the dryBulbTemperature from the ‘Import EPW’ component, the univeralThermalClimateIndex (UTCI) output from the ‘Outdoor Comfort Calculator’ component, or the standardEffectiveTemperature (SET) output from the ‘PMV Comfort Calculator’ component. If you are using this component to evaluate shade for a passive building with no heating/cooling, this input can also be the indoor temperature of the zone to be shaded.
This is not the problem, but good that you clarified the definition.
I’m still having the same problem as above. So what i did is to bang windows and shades to pick just one of them each time. It works this way. So i assume there is a problem in the script when there is more than one element to analyze.
… Checking a bit further, the problem is with the amount of windows. It only accepts one, which thinking about it, has a logic of its own. No warning with the amount of shades.
I probably need to include this somewhere in the component description but the shades and windows are read as a parallel data tree structure. So, if the shades are not on the same data tree branch as the window that they are shading, the two will not be analyzed together. I found that data tree structure is necessary when you want to do a shade benefit for a large multi-zone building and I made the “EnergyPlus Window Shade Creator” to help make sure that these data trees are correctly aligned for large buildings.
So, the component does accept multiple windows but each window should be on its own branch with a corresponding set of branches that include the shades of each window.
Makes completely sense. The thing is that i’m hooking the outputs from the ShadeCreator, for both the windows and the shades. So i assume are branched as needed. Moreover, i know that since picking individual branches fit both of them. Moreover (#2) the same outputs work well with the E+ShadeBenefit.
I’m using Dimitrius file as a basis for the example.
When i connect the output of the EPWindowShades to the LB_ComfortShadeBenefit inputs i’m getting the error i mentioned (See 1 in file). When i exploded the trees for both shades and windows and connect just one branch of each it works (see 2). You can see that both trees corresponds well.
Ah. Now I understand. If you are planning to use the comfort shade benefit to evaluate building shade, you should usually send the zone Operative temperatures through the ZoneData input of the Zone Shade component. This way, you can evaluate the shades in terms of indoor comfort (although this is probably only meaningful when your building is not conditioned).
If you want to evaluate your building shade in terms of outdoor comfort (which seems a bit weird but nonetheless possible), all that you have to do is duplicate the outdoor air temperature data to match the number of windows like so:
The attached file shows how to do all 3 of these cases (Energy, Indoor Comfort, Outdoor Comfort)