Hi Folks,
any idea why I could be getting different results for heating - discrepancy between normalized heating from sql and eui equipment?
The EUI component currently lumps the service hot water heating with the space heating. These two types of heating are separated when using the “HB Read Room Energy Result” component. So that is my guess as to why they are different.
I’m eventually planning to add templates for service hot water systems, which will cause the hot water to be reported as a separated term by the EUI component.
1 Like
Its not only with heating. There is something else going on. I have a model with ideal air systems - so there should be no Fans, Pumps, and Heat Rejection energy (the “Read Room Results” component does not show any fan/pump outputs). Cooling and Heating do not match.
Hi @ApoorvGoyal ,
The screenshot doesn’t really give me enough to understand all of what’s going on (a sample file would be a lot more helpful). However, it looks like some of the Rooms in your model might be using ideal air systems while others are using more detailed systems. We could know for sure if you were to provide a sample file.
Hi @chris , thank you as always for taking time to answer our questions. I have also been obtaining discrepancies in the values obtained from the HB EUI component and was wondering if it would be possible to know exactly what output values is it reading from the sql file? In my case, for example, the pump energy values from the EUI component don’t match by a order of magnitude with the ones I manually obtain from the “ReadCostumResult” components.
When in doubt, the EUI component gives you the most complete account of energy use across the model. So most of these discrepancies are probably because one of the timeseries outputs isn’t being requested or imported. If anyone uploads a minimal file, I can probably tell you what timeseries output you are missing.
1 Like
Thank you for your fast answer, Chris! As you predicted, I forgot to request an output from the ConstantFlow Radiant System I am trying to model, now the numbers match. In any case, it’s very helpful to know that the results from the EUI component can be used as “ground truth” to compare other values. Thanks for all the amazing work with Ladybug tools, it’s always a pleasure to keep learning with them.
1 Like
Apologies for opening this topic again, but I am still getting small discrepancies on my EUI results. From what I have observed, it seems like the values obtained from the EUI component are always the sum of the electricity annual value (GJ) and electricity maximum value (W). See here the output of the component and the summary table from the sql file.
For example, for the equipment electric energy: 696.4kWh = 2.25*277.78 + 71.4. The first number, the electricity annual value, is always in perfect agreement with the sum of individual outputs I get from the sql file for all 4 EUI categories. I am confused (both conceptually and units-wise) by the part in which the component adds the electricity maximum value, but I wanted to double-check if I am missing something from the whole EUI calculation process. The same values are also displayed in the GHpython component when plotting the values parsed by the “tabular_data_by_name” function.
Thank you for your help! I also forgot to mention that I am running a custom idf file with the “HB Run idf” component.
Hi @Edu_Gascon ,
All of the EUI results come from the “End Uses By Subcategory” and the “Building Area” tables that you can see in the HTML report.
As the component says, the units are kWh/m2 when ip_ is False or None and kBTU/ft2 when ip_ is True. So it’s automatically doing the conversion from GJ for you.
Hi @chris ,
Thank you for your answer! My concerns are not exactly related to the conversion of units but to the fact that a peak electricity value (in W, not GJ) is included into the final end use calculation. There are two “End Uses By Subcategory” tables in the HTML report, one for total energy consumption and another for peak demands at a specific time of the year. Both values seems to be added together (as far as I understand) by the GH component. Shouldn’t we only worry about the first? Thanks!
I don’t understand since the results are matching on my machine (admittedly with some small rounding errors of around 0.1%):
We have made a number of improvements since LBT 1.2 and I recommend upgrading your version of the plugin to 1.3. Maybe this is just an old bug that was fixed. If you still have the error in LBT 1.3, then pleas upload a sample file that recreates the issue.
1 Like