[Solved] ExportToOpenStudio vs runEnergySimulation - Results differences

Hi,

I'm performing thermal comfort analysis for some project.

I'm trying to migrate from using the runEnergySimulation component to exportToOpenStudio as recommended by Chris.

Comparing the results from using the same setting for both options i get different results. So i'm assuming that the exportToOpenStudio is adding additional default values. Otherwise i can't explain the differences, that sometimes are significant.

Attached a couple of images showing the issue.

Thanks,

-A.

Attachments:

runEnergySimulation.JPG, 138 KB
exportToOpenStudio.JPG, 142 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Abraham Yezioro on October 16, 2016 at 12:48pm

Hi Chris,

Some changes in the results but still big differences.

Two inputs differ from yours: i set the maxOutdoor (28C becouse i want to ensure the wind themperature doesn't rise the body temperature), and the stackDischargeCoeff_ to 0.25 (no insect screen).

Checking the IDF files i don't see much differences (attached). But the block ZoneMixing in the E+ has 14 objects and the OS has 7 (the number of zones is 7, so i don't know why the E+ doubled the objects). Also their values are different (DesignFlowRate). I think there is an issue here ...

Any thoughts?

Thanks,

-A.

Attachments:

EPlus.idf, 251 KB
OS.idf, 233 KB

Permalink Reply by Abraham Yezioro on October 16, 2016 at 3:01pm

Hi Chris,

I kept looking for more information that may help the debugging. I separated the naturalVentilation results per zone. I can see that the OS results are higher that those of E+. There are some zones that the differences are more sensible. See image:

-A.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 16, 2016 at 7:43pm

Hi Abraham and Chris.

Abraham, which version of EnergyPlus are you using to run the analysis? Are you both using the same version of EnergyPlus and OpenStudio?

Permalink Reply by Abraham Yezioro on October 16, 2016 at 8:00pm

Hi Mostapha,

I thought about this and checked a few days ago. Bith cases run the same E+ version, which is the one installed in the OpenStudio directory. In my case, OS 1.12, the versionn is 8.5. See both images.

In this respect i wanted to ask if this is what it is supposed to happen. I mean, in theory i don't need to have an independent E+ version because HB will use what is in the OS?

EnergyPlus run:

OpenStudio Run:

Thanks.

-A.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 16, 2016 at 8:57pm

Thanks Abraham. I ran a idfdiff using eppy to see what are the differences between two files. Among the objects that can be related to ventilation, number of ZONEMIXING objects are different between two files.

Check the attached csv file for full list of differences.

Mostapha

Attachments:

diff.csv, 135 KB

Permalink Reply by Abraham Yezioro on October 16, 2016 at 9:13pm

Thanks Mostapha,

Yes. I mentioned this in one of my previous comments. The E+ has 14 objects while the OS only 7 (as the number of zones). Also the values of the DesignFlowRate are different.

-A.

Permalink Reply by Abraham Yezioro on October 19, 2016 at 4:45am

Hi,

Wanted to report that this will be difficult to debug.

I tried a simpler example: Defining zones by volume and defining zones by surface. For both of them the results match exactly. This is GOOD.

The example that is making trouble works surface by surface. The difference between this and the previous is that this one have AIRWALLS and the previous doesn't.

I suppose this is the reason why the ZoneMixing is created. The new test files don't have this Block of information in the IDF file.

As a result of the above my instinct says that the AIRWALLS conditions should be checked in the code to see what is the difference when creating IDFs either with E+ or OS components.

To remind from previous posts:

The model has 7 windows for all zones (7 zones. 1 zone has 2 windows and one zone has no windows). For the ZONEMIXINGblock the E+ IDF duplicate the number of objects (14) in relation to the OS (7).

You can see in this image how the ZoneMixing objects are connected (Bold end of line is the Source Zone Name field; the plain end of line is the Zone Name). You can see that the E+ is connecting for both ends and the OS only one end. Something to think, to check or to be worried about?

-A.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 19, 2016 at 7:00am

Thanks, Abraham. You've found the issue already. Let's see if Chris has any comments on this. I've overbooked myself for the next two weeks but hopefully I can take a look after that if it's still an issue.

Permalink Reply by Abraham Yezioro on October 19, 2016 at 7:06am

Thanks Mostapha.

Crossing fingers this is the reason and it is easy to fix.

BTW, from the image above we can see that in OS, the only double connection happens between z6 and z7, while there is a missing connection between z3 and z6.

-A.

Permalink Reply by Chris Mackey on October 23, 2016 at 10:48am

Abraham and Mostapha,

Thank you very much for finding the error. I have what I need to fix it now and I am sorry that I am just getting around to it now. I'll post back here in an hour with fixed components.

-Chris

Permalink Reply by Chris Mackey on October 23, 2016 at 11:38am

Phew!

Man, this bug was like finding a needle in a haystack! It was just one little line that needed changing but the bug only affected cases where you have several air walls between zones, which made it so hard for me to replicate on a smaller scale. It really required a file of this size and created surface-by-surface to replicate.

To be clear, the bug was in the OpenStudio component in that it was only writing out a single mixing object for each zone instead of the multiple objects needed to model cross-mixing of air in between zones.

This bug has been fixed here:

https://github.com/mostaphaRoudsari/Honeybee/commit/f12da7f6534bb49...

.. and in the attached file.

Thank you again, Abraham and Mostapha, for your persistence with addressing this issue. As they say, any computer issue is solve-able with enough perseverance. I am happy to finally say that this case is closed!

-Chris

Attachments:

munotoA115.09.16ASHRAEEU_AY_Updt_FIXED.gh, 1.9 MB

Permalink Reply by Abraham Yezioro on October 23, 2016 at 11:54am

Great news Chris!!

I'll check it, but i'm sure it going to be fine.

As you know this case is very important for me and my student, and it was necessary to solve, otherwise phasing towards the OS was not going to be possible, not now and not later.

It was indeed hard to find, and this is another lesson that you always need to check ALL the outputs. In this case the IDF files which are the output of the components, to understand they are well written.

Thanks again,

-A.