HB Export to Open Studio version: FEB_20_2019 - results changed

Hi there,

Today I noticed a significant change after running exactly the same energy simulation with Honeybee as just 2 days ago. The problem is with heating, which is now way too high, and that is causing unrealistic storage values. All inputs were exactly the same.

RESULTS TODAY:

RESULTS 2 DAYS AGO:

I noticed that the HB Export to Open Studio component had changed its version date from 20 Nov 2018 to 20 Feb 2019, could this be an issue with the new release? The simulation “readMe!” is showing no errors.

I attached my GH file with internalised data.

Best,
Aga

1_ENERGY.gh (1.4 MB)

Is it possible that you forgot to connect mechanical ventilation event to energy balance chart?

Hi @mostapha,

The mechanical ventilation was connected, it’s included in the energy balance chart above as one of the shades of blue.

@aguosha ,
Your grasshopper file is way too large and disorganized to be of use here. All that I can say is that none of the changes that have been made to the OpenStudio component since NOV_20 would have an obvious effect on your energy balance here:

Perhaps you are using a different version of OpenStudio or something else has changed in your Rhino model or GH definition.

1 Like

Thanks @chris.

You are right, the error is not related to the changes in the component. I have found that the reason was I changed the SolveAdjacencies Boundary Conditions from default “SURFACE” to “AIRWALL”.

Following this I have another question.
I split my model into 2 zones with an air-wall in between, because I intend to have two different lighting schedules that are created based on daylight results. I ran the energy simulation having a) just 1 zone; b) 2 zones separated with air-walls, using a default lighting schedule for medium office in order to compare the results and see if they are equal. It occurs that they are not exactly equal:

… … … … Cooling… Heating… /(kWh/year)
2 zones … 47.5… … 313.7
1 zone… … 41.6… … 241

In addition to higher energy intensity, in the case of a 2-zone model, the storage event in the energy balance chart is rather high, as opposed to almost negligible in the case of just 1 zone.

Energy Chart for 2 zones with an air-wall:

I would prefer to use the 2-zone model, but from the chart it looks like there might something wrong with it.

My question is:
Why is there a difference in energy results between the two modelling methods?

I attached my GH file - clean and tidy this time so I hope it’s easy to navigate :slightly_smiling_face: Sorry about the last file, such a mess I know :woman_facepalming:

2_Daylight_Energy.gh (351.1 KB)

@aguosha ,
That’s a better explanation for the change in results.

Also, seeing the energy balance graphic, it looks like the your two simulations actually have very similar overall energy balances. So the two types of simulations are actually very similar and it’s just that the heating/cooling energy needed in both cases is extremely small such that small rounding errors make it seem like there’s a big difference.

Generally, it looks like the building is so tightly insulated with such a low infiltration rate, mostly adiabatic surface area, and highly efficient heat recovery that it never really enters into an intense heating mode. So all that it needs form the ideal air system is cooling but, given that the climate file you are using has cool outdoor air most of the year, the economizer in the ideal air system takes care of all this cooling for you. I might question the realism of the adiabatic surfaces in your model if you imagine that this test box is supposed to represent a full building with a much higher exposed surface area to volume ratio. I would also question the cost it would take to implement such an efficient heat recovery system in a building that is dominated by ventilation load. But, if your goal is to make a model that has virtually no heating and cooling load, you have succeeded!

1 Like