A couple of questions about output variable setting in HB:
how to specify a particular output variable in HB? (seems the HB_generate_EP_output component have a few, although sufficient, options)
how to specify Output:Meter variables, such as Electricity:Building, InteriorLights:Electricity, InteriorEquipment:Electricity, that are used to calculate Plug Loads?
What if I want to get the following output variables?
Zone Total Internal Total Heating Energy/Rate (which is total internal gains)
Zone Windows Total Heat Gain Energy/Rate and Zone Windows Total Heat Loss Energy/Rate for calculation of net window gains
You can just type them and connect it to the component. As you can see in the image the outputs of Honeybee Generate EP Output component is standard EnergyPlus syntax. You just need to follow the similar pattern.
Once the study in done and you read the results back you can find them at otherZoneData output.
It seems the read EP result component can’t process the following output variables, either individually or as a group, appended to the Generate EP Output component, although the results for these variables are in the csv file…
Advices are appreciated!
Output:Variable,*,Zone Total Internal Total Heating Energy,Hourly; Output:Variable,*,Zone Windows Total Heat Gain Energy,Hourly; **Output:Variable,*,Zone Windows Total Heat Loss Energy,Hourly; ** Output:Meter,DistrictCooling:HVAC,Hourly; Output:Meter,Electricity:Building,Hourly; Output:Meter,InteriorLights:Electricity,Hourly; **Output:Meter,InteriorEquipment:Electricity,Hourly; **
There are several things that have to be clarified here:
It seems that you do not need to add any other outputs other than those already in the ‘Generate EP Output’ component to get the information that you desire. Just set zoneEnergyUse and zoneGainsAndLosses on the component to true and you get the equipment load (equal to equipment gain), internal lighting load (equal to lighting gain), the people gain, and the total solar gain. If you also need window heat loss, you can get this on a window-by-window basis by setting the surfaceEnergyAnalysis to true (and, after the simulation, use the ‘Surface Data Based on Type Detailed’ component to pull out just the window data from the list of al surfaces).
There was a bug in the otherZoneData of the ‘Read EP Result’ component when you set the “normByFlrArea” to True. Thanks for finding it. I fixed it in the attached GH file so that you can get those specific Zone-level outputs if you want them instead of what I have suggested above.
There is currently not a component to read meter outputs mostly because this information would be misleading with the ‘Run Energy Simulation’ and it use of an ideal air heating/cooling system. The energy from ideal air systems is not factored in meter outputs and you need to specify a complete, real HVAC system for such thermal outputs to affect things like meter electricity or meter fuel. Now that development is picking up on the OpenStudio component, which can write these complete HVAC systems, we will eventually have a new result reader that parses the E+ SQL output (including meter outputs).
Hi, Chris, thank you very much for your detailed explanation and the fix of the component!
However, I still got the following issue with the updated “Read EP Result” component:
even when the normByFloorArea is set as False, the caption for the zone heating loads visualization still shows “floor normalized heating energy” (see image 1 and 2) below
When I try to visualize “zone windows total heat gain energy” normalized by floor area, the caption shows “average” instead, and the color legend is not changed to floor normalized values. (see images 3 & 4 below)
Honeybee by default assumes that you usually want to color zones with energy intensity rather than total energy. If you want to see energy and not energy intensity, you have to set both the ‘normByFlrArea’ to false on the ‘Read EP Result’ component AND the ‘normalizeByFloorArea’ to false on the ‘Color Zones’ component.
The reason why the windows energy was showing up as an average was because the component was treating it the same way that it does temperature (since not all outputs of E+ can be meaningfully normalized by the floor area). I have tried to re-write the function that senses the data type in the color zones component but please understand that this is a difficult function to write since E+ has thousands of outputs and I can’t write something to catch them all.
So, i connect a boolean toggle to both the normByFloorArea on Read EP Restuls and the normalizeByFloorArea on Color Zones so that the normalization function can be set as on/off for both components at the same time to avoid confusion.
Am I correct?
Correct viz for issue 1:
why one of the zones have different total internal loads is because it has a different floor area (all zones have the same building program, and therefore the same floor area based internal loads definition)
once the total zone loads are normalized by floor area, all the zones have the same value now.
It seems the ColorZones component can visualize floor-normalized data for otherZoneData in Read EP Results now. However, the 3D Chart component is not responding to the normalized data, and it still shows the non-floor-normalized data for otherZoneData variables.
Does this means the 3D Chart component needs code revision to cope with this kind of scenario?
I forgot to change the name of the data in the Ladybug header when you set the floor normalizing boolean on the result reader to ‘True’. Also, I was not actually dividing the values by the floor area inside the component. I have fixed this in the attached file and on the github.
To clarify, there are two places where you can floor-normalize the incoming data mostly for control over whether you want more display options or more speed. If all that you care about is energy intensity, you might as well normalize it on import and, that way, all processing of the data after it will be fast (including coloring of zones). If you want the option to either normalize it later or not, you should import the data as-is (not normalized) and, that way, you keep the option to normalize it later.
