openstudio 2.2.0 vs. 1.14.0 airloop

asked 2017-08-31 17:06:36 -0500

Matt Koch
1998 ●2 ●17

updated 2017-09-01 03:33:22 -0500

I appears that OS:AirLoopHVAC has gained a few more entries in OpenStudio 2.2.0 compared to 1.14.0. Notably, these appear to be:

Return Air Bypass Flow Temperature Setpoint Schedule Name
Demand Mixer Name
Demand Splitter A Name
Demand Splitter B Name
Supply Splitter Name

Is it crucial that these be assigned correctly, or can they remain at their default values. I created my original OSM file in 1.14.0, and after importing to 2.2.0, these extra fields show values which I am sure are wrong if it were critical that they be correct. Then again, if I had to assign something to them. I would not even know what that would be. That is to say, I can vaguely imagine where the demand mixer is, namely the branch collecting the returns form all my zones (?). But what are the demand splitters A and B? And, there really seems to be no supply splitter, as all my return just goes right back to the AHU?

I am concerned because the very same file shows differences:

|-----------------------------------------------|--------|--------|
|              Value                            | 1.14.0 | 2.2.0  |
|-----------------------------------------------|--------|--------|
| EUI                                           | 49.91  | 49.07  |
| time setpoint not met during occupied heating | 82.0   | 79.33  |
| time setpoint not met during occupied cooling | 130.5  | 915.17 |

edit retag flag offensive close merge delete

Comments

Please use existing tags to the extent possible. Nobody is subscribed to the tag '1.14' or 'vs.' Thanks.

__AmirRoth__ ( 2017-08-31 17:15:39 -0500 )edit

2.2.0 uses a newer version of EnergyPlus than 1.1.40. It is possible that the E+ version change accounts for the differences, although the change in unmet cooling seems high. A good test would be to take the 1.14.0 IDF file, use E+ version translator to change it to EnergyPlus 8.7, and then run that with EP Launch, and compare that to the 2.2.0 run.

David Goldwasser ( 2017-08-31 17:22:48 -0500 )edit

Took the liberty of making an ASCII table for your differences, too hard to read otherwise.

Julien Marrec ( 2017-09-01 03:33:06 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2017-09-01 03:18:54 -0500

Julien Marrec

29032 ●85 ●74 http://www.effibem.com/

TL;DR: The fact that you have a discrepancy in your results between OS 1.14.0 and 2.2.0 is not coming from this. You can safely ignore these new fields.

I'm not sure why you actually see the splitter/mixer names in the OS App now (I don't see any reason to, you shouldn't be able to change them... but might be missing something), and the return air schedule either since it's not even implemented.

Demand Mixer Name and Demand Splitter Name show you the name of the demand mixer/splitter:

Demand Mixer and Splitter

In the above image, Demand Splitter B and Supply Splitter are showing you bogus stuff, they're actually empty, the method returns boost::none. It's showing you the name of the airLoopHVAC for some reason...

Supply Splitter Name and Demand Splitter B only apply if you have a Dual Duct airLoopHVAC. Looking at the source code, A is the hot air, B is the cold air.

Dual Duct

ReturnAirBypassFlowTemperatureSchedule isn't even implemented in OpenStudio at the moment. See source code

edit flag offensive delete link

Comments

@Kyle Benne I'd consider this a bug.

Julien Marrec ( 2017-09-01 03:19:31 -0500 )edit

@Julien Marrec It is a bug, those fields shouldn't be exposed in the GUI and needs to be updated in the OpenStudioPolicy

MarkAdams ( 2017-09-01 12:56:23 -0500 )edit

But it's already "HIDDEN" in 2.2.0 (see here)

Julien Marrec ( 2017-09-04 10:01:52 -0500 )edit

These fields are still exposed in OS 2.5. If this is a "bug", does this mean we should leave these fields as the default values? What happens if we change them? Are the changes superseded or will they be carried through the model?

ethankheil ( 2018-06-15 16:12:10 -0500 )edit

add a comment

answered 2017-09-01 12:16:16 -0500

Matt Koch
1998 ●2 ●17

updated 2017-09-06 18:21:58 -0500

So, it took me a while, but I did as David Goldwasser advised for my proposed building.

I took the original OS 1.14.0 model and exported an .IDF file from it and ran it with EP 8.6.0 Launch. Then I opened the OS 1.14.0 .OSM file in OS 2.2.0 and saved it as an OS 2.2.0 .OSM file. From that, I also exported an .IDF file and ran it with EP 8.7.0 Launch. In addition, I used the EP 8.7.0 Version Updater to convert the EP 8.6.0 .IDF file to an EP 8.7.0 .IDF file and ran that with EP 8.7.0 Launch (it had the same results as running the "native" EP 8.7.0 .IDF file).

The results for this proposed building are summarized below:

Variable	Unit	1.14.0 & 8.6.0	2.2.0 & 8.7.0
Setpoint Not Met Occupied Heating	[h]	82.0	79.33
Setpoint Not Met Occupied Cooling	[h]	130.5	915.17
EUI	[MJ/m2]	566.81	557.23

I also did this for a reference building, which is only different from the proposed building in that it has different constructions, has substantially fewer shading surfaces and that it uses parallel Fan-Powered Boxes (FPB) powered by Roof-Top Units (RTU) instead of simple VAV terminals powered by chilled water from an air-cooled chiller.

The results for this reference building are summarized below:

Variable	Unit	1.14.0 & 8.6.0	2.2.0 & 8.7.0
Setpoint Not Met Occupied Heating	[h]	27.17	27.17
Setpoint Not Met Occupied Cooling	[h]	3.33	3.33
EUI	[MJ/m2]	770.66	770.66

So the proposed building's performance depends on the version of EP, but the reference building's performance does not???

I am not sure what to make of this, but EP 8.7.0 seems to work differently from EP 8.6.0 for the proposed building (with many shading surfaces and chilled water VAV). Has the shading algorithm been altered between EP 8.6.0 and EP 8.7.0? I would think that is more likely than anything having changed with the treatment of chilled water or constructions?

Sorry, not really an answer, I know, but could not post this as a comment, either.

>>> EDIT to accommodate Julien Marrec file comparison suggestion <<<

Thank you Julien. I followed your advice, and here is what I get for the Reference building – sorry for the lengthy listings.

To compare the OpenStudio 1.14.0 export to the OpenStudio 2.2.0 export, I did not need to sort. In general, almost all schedules had been given new hexadecimal numbers, though they were being referenced properly as far as I could tell. The only true differences appear to be the following.

A) Outdoor Air Specification

I think what I want is “Outdoor Air Schedule Name”, not “Outdoor Air Flow Rate Fraction Schedule ... (more)

edit flag offensive delete link

Comments

Do a diff of both IDF files (perhaps make sure you open both in the IDF editor and save them as "Sorted"). Use a diff tool (compare for notepad++, winmerge, whatever). Hopefully that's going to not show too many differences, and you'll be able to see what settings got changed.

Julien Marrec ( 2017-09-04 09:58:54 -0500 )edit

Yeah I don't see any relevant difference from your diff (for eg: the WaterHeater:Mixed IndirectHeatPrimarySetpoint is the historical behavior (see here). SingleSetpoint for the plant loop is the default.

Julien Marrec ( 2017-09-06 03:05:55 -0500 )edit

The DSOA schedule has just been renamed (see 8.5 versus 8.7)

Julien Marrec ( 2017-09-06 03:06:05 -0500 )edit

The ZoneCapacitanceMultiplier:ResearchSpecial doesn't have any multiplier defined and so shouldn't have any impact anyways. Prior to 8.7 there wasn't any "Name" nor ZoneList Name fields, probably just applied to all zones.

Julien Marrec ( 2017-09-06 03:10:38 -0500 )edit

Curious, I just spent some more time with this and I noticed the "eplusout.err" file from the 2.2.0/8.7.0 run is not showing an error that is immensely copious (40,634 times) in the "eplusout.err" file from the 1.14.0/8.6.0 run, namely the following: * Warning * Too many figures [>=40000] in a shadow overlap So, even after I set "Shadow Calculation" - "Calculation Frequency" to 15 and "Maximum Figures in Shadow Overlap Calculations" to 40000, 8.6.0 still coughs up these errors, but 8.7.0 does not? Was there a change in the shading algorithm between 8.6.0 and 8.7.0?