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.
Abraham,
I know that there is a very small difference between how the two components write out the ideal air system. Specifically, the E+ component uses a template system that is easy to add to the model but harder to size correctly. The OpenStudio component writes out a full Ideal Air system that has more detail and is sized more robustly to handle the loads in extreme times. It is possible that this may account for the difference.
Is this a simulation that you are running with the ideal air system?
If not, I don’t know of any other major differences between the two except that the OpenStudio component has an implementation of daylight controls that shouldn’t affect anything since it is turned off by default. In this case of not having an ideal air system, upload the gh file (no matter how large) and we will get to the bottom of the difference.
-Chris
Hi Chris,
I checked a bit more thoroughly. This happens with both conditioned and unconditioned models.
I’m attaching the unconditioned example (needs the 3dm also. Sorry for not internalising).
Disable the solver before opening. It can take a while to run.
Also attached the IDF files created by each component. The differences are minimal … if any, so i can’t explain the differences.
Any thoughts?
Thanks,
-A.
munot o - A1_Clean.3dm (710 KB)
E+.idf (253 KB)
munot o - A1 - 15.09.16 - ASHRAE-EU_AY_Updt.gh (1.94 MB)
Abraham,
It was just too difficult to test anything with your file but I was able to replicate the issue with a smaller model and simpler GH file. I got the OpenStudio component giving far worse comfort than the E+ component even though the average temperatures were similar:
It turns out that it was not the known difference in ideal air system between the components (swapping out the ideal air template into the OpenStudio file did not affect the results). Rather, it was a bug in the OpenStudio component that was causing incorrect default constructions to be written for some of the surfaces. I think your case wasn’t affected as much because you are overriding a lot of the default constructions. I fixed this bug here:
https://github.com/mostaphaRoudsari/Honeybee/commit/6b185b5c8b7d9b1…
And I now get results that match very closely.
Let me know if updating your components fixes your issue, Abraham.
-Chris
Hi Chris,
Thanks. It looks good … for your example. Unfortunately for mine the differences remain the same as in the original message. I mean, no changes with the updated component (6 October).
I tested the surfaces temperatures for both E+ and OS. there are differences of 1 degree in the minimal and 0.5 in the maximal scale of the legend for the typical weeks (hot and cold). As i said before, comparing both IDF files they are pretty much the same, except for the ScheduleTypeLimits, where the E+ writes 91 objects and the OS only 8-9. Also the OS writes some Schedule:Week:Daily and Schedule:Daily:Interval for Warehouses and they are used for the calculations. Needless to say that i defined for all zones MidriseApartment program.
Additionally, you are right. I defined almost any possible value, so practically no defaults were left to be used.
Last thing, I understand that both components run EnergyPlus 8.5 installed in the OpenStudio installation directory. I don’t have installed 8.5 besides that. Is this right?
Any suggestions?
Thanks again,
-A.
Abraham,
The warehouse schedule difference sound suspicious (do you know where in your script these are being defined?)
If it’s not this, then the only significant difference is the ideal air system. Can you check with the new EIO component to see if the size of your ideal air system is very different for the two simulations. This discussion includes an image of how to do this:
http://www.grasshopper3d.com/group/ladybug/forum/topics/heating-and…
You might just want to oversize both systems a lot (using EPSimPar) to ensure that all setpoints are always met.
-Chris
Hi Chris,
I don’t define anywhere something related to Warehouses. I strictly defined each zone as MidriseApartment. You can see in this image where this is happening in the script:
As for the schedules, also this image shows where i’m defining/assigning all of them:
BTW, the warehouse stuff appears ONLY in the exportToOpenStudio option.
Finally, i’m not conditioning the zones. Explicitly i asked to set the isConditioned_ input in the HB_createHBZones to False. The discussion you mentioned approaches this differently oversizing the heating/Cooling so you never need the AC. The IDF created don’t have any definition of IdealSystems, so i don’t believe this is the problem. If you want to see the IDF files you can see them above (attached in a previous message).
Weird …
Thanks,
-A.
Abraham,
I checked and the warehouse schedules are not being used at all even though they are being written (so that is not it). Much of the differences in the way the schedules are written seems to do with the fact that OS does not support CSV schedules and so we have to write these in after IDF translation. I’m trying to test your GH file but I’m getting errors from the simulation:
This really seems to be too complex of a model for me to separate honeybee code issues from the energy modeling issues.
The best I can offer if you are able to run your model on your machine without errors is to try producing an energy balance graphicof the two models and see if there is one specific term that is out of order. This will at least give us a place to start looking.
-Chris
Hi Chris,
So you gave me some homework and i did it 
There are differences, some of them big, specially with NaturalVentilation and Storage results:
And the summary of the differences are (i left only those that are significant):
As you see, naturalVentilation is giving higher loses in the OS option.
Attached also an excel with all the data. Maybe it will help.
Is this useful for debuging?
The error of the simulation is related to non-convex surfaces. Is severe but the simulation runs. I need to check where is (are) the bad surface and correct it.
-A.
Compare_EnergyBalance.xlsx (20.7 KB)
Abraham,
This is great and thank you for doing the homework :). At least now we know now that the issue seems to be with the natural ventilation since the other terms are looking really similar. The storage term is just computed as the remainder of the other terms (to make the energy balanced) so it is really only reflecting the difference in the natural ventilation between the two simulations.
Let me see if I can re-create this difference on a small scale and, hopefully, this will then fix your issue.
-Chris
Abraham,
I unfortunately can’t seem to replicate the error on a small scale. I’m getting results that match perfectly:
-Chris
TryToRecreateNatVentError.gh (674 KB)
Abraham,
I took another look at your file and realized that you are also not setting up the nat vent component so well. If you use the nat vent specifications that I have in the previous file that I attached, let me know if you get comparable results.
-Chris
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.
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.
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?
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.
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
diff.csv (135 KB)
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.
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.