Hi, when I use the annual-energy-use recipe in pollination, I have noticed that functions a bit differently than the native LBT version of the EUI component in that sometimes the order of the EUI results from pollination show up in a different order for different runs that are being read. For example, sometimes the heating values will come before the cooling values, and sometimes the other way around as pictured below.
I was also wondering if the Pollination recipe for anual-energy-use could also include the gross floor area as an output? This would be very useful quickly computing the total energy usage of the building. Ofcouser, I can access the sql file and use that to extract this information, but that costs a non-neglibigle amount of time when done for many simulations.
Lastly, I have found that both the pollination annual-energy-use recipe and the LBT EUI component will drop from the list any loads that amount to zero. Can the components be modified to include the zero loads in the list? This has downstream impacts, which, while workable when identified, can lead to erroneous follow on analyses. The two pictures here are from a single study where the output results were being read using the wrong indices (heating was read as the cooling load, and cooling was read as the interior lighting load).
The order of the results as they appear in the EUI output of the isn’t something that we can easily control. I don’t want to go too much into the weeds about the reason because it has to do with the fact that EUI from the recipe is written in a JSON file and JSON maps to a Python dictionary, which is an unordered data structure.
But the good news is that the output from the HB End Use Intensity component will always be in the same consistent order. So just connect up the sql output from the annual-energy-use recipe to that component and you’ll get a list of end uses that is always in a predictable order.
The recipe can be changed but, again, it might just be faster and more practical to use the sql output from the annual-energy-use recipe. The EUI output is really just there to be human-readable and it is not in a good format if you want certain values to always be at a certain list index. It almost sounds like you don’t really need to use the annual-energy-use recipe at all. The custom-energy-sim recipe might be able to give you everything you need. The only reason why you might need to run annual-energy-use instead of custom-energy-sim is if you want the special stylized HTML report that the annual-energy-use recipe outputs. If you don’t need that report, then you might as well run the custom-energy-sim recipe and your simulation will be a little faster.
The vast majority of EnergyPlus’s end uses are zero for a typical simulation so that’s why we scrub them out by default. But you can see the “End Uses” table that we pull the data from has lots of zero slots in it if you want them:
You just need to do a little processing on the data since E+ throws some extra things into the table that are not energy use (eg. water use and time of peak). But you get values for all of the end uses that E+ can report, which typically means lots of zeros but also means that the same end use is always at the same index.
