search

kbenne / cbecc

Automatically exported from code.google.com/p/cbecc
0 stars 0 forks source link

CBECC v3 support issue - Gold Coast model #903

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
We have been working on a model using IES VE 2014 with the CBECC V3 engine and 
have some pressing support questions we would like your assistance with please.

The 2 files attached are the latest iteration of the XML file and an archived 
CAB file of the VE model. The model itself is a small one storey maintenance 
workshop building.

We currently have 3 points we would request your help on:

1.       Standard Model Unmet Load Hours

a.       When we run a simulation, using either the CBECC API (IES VE 2014 ) or 
through CBECC itself, we are notified of unmet load hours (UMLHs) for heating 
in the standard model. We have read section 2.6.2 “Sizing Equipment in the 
Standard Design” which notes to increase the plant in 5% increments until the 
loads are met. However we are unable to find a way to do this. Please can you 
advice on how this should be performed and why we would see unmet load hours in 
the standard model as we are under the impression the auto sized loads should 
always avoid this condition.

2.       Occupancy Sensing for Lighting

a.       We have occupancy sensing throughout the building design and would 
like to incorporate within the model. Could you please advise on the set-up 
needs here.

3.       Terminal Unit Cooling Coil

a.       In one of our systems we have cooling coils in the terminal units 
however we can only input heating coils and fans. How do we incorporate a 
terminal unit with a fan and cooling coil, and also a terminal unit in a 
different space with a fan, cooling coil and heating coil? This system is 
supplied by a main air handling unit which also has a fan, cooling coil and 
heating coil.

Could you also confirm you have received this email successfully and provide an 
estimated response time.

Original issue reported on code.google.com by f.le...@gmail.com on 7 Jan 2015 at 11:02

Attachments:

GoogleCodeExporter commented 9 years ago 
For taking credit for occupant sensors please refer to the FAQ page: 
http://bees.archenergy.com/faq_loads.html. 
Q: How can I claim Power Adjustment Fraction (PAF) credits for the lighting in 
my space?

Regarding item 3 below, we do not have the ability to model cooling coils in 
conventional terminal units (VAV boxes).  However, if I had additional 
information about the system that you are trying to model, I might be able to 
identify a configuration of available components that would provide a 
reasonable representation of the actual system.

Original comment by rhedr...@archenergy.com on 12 Jan 2015 at 9:50

GoogleCodeExporter commented 9 years ago 
I've been focusing my review on the occupied UMLHs in the baseline design of 
this model (user issue #1). It an IES generated model using CBECC-Com v3, so 
EnergyPlus 8.1.

All zones in the model have roughly 200 heating UMLHs, no cooling UMLHs. The 
model is in CZ6, which is relatively mild (99.6% heating is 40.6F). It is PVAV; 
no special process systems.  One unique item I found is all floors in the model 
have an exterior boundary condition, so higher than normal envelope loads.

I have checked that there are no inconsistencies between HVAC operating 
schedule and occupancy schedules that might be causing this issue.

I have reviewed timestep data and see that when zones call for heating, the 
boxes are opening up to the max heating flow ratio; they are 'Reverse' action, 
so 50% of max flow. However, there is little heating coil output and the zones 
are not maintained to heating Tstat setpoint during cold OAT hours. 

I have run the following iterations:

a) Autosize all HW heating coils. This alleviates the heating UMLHs. However, 
comparing to the hard-sized values, I find that the autosized values are 
smaller than the hard-size model by 25%, as expected since the hard-sized are 
the auto-sized values multiplied by 1.25 sizing factor.  This indicates this is 
not an under-capacity issue.
b) Autosize ONLY one (1) terminal heating coil. This DOES NOT alleviate heating 
UMLHs. 
c) Autosize ALL BUT one (1) terminal heating coil. This reduces heating UMLHs 
to about 100 for all zones. 
d) Use 'Normal' action damper control. This alleviates the UMLHs, again 
indicating this is not a under-capacity issue.

I am stumped. Kyle, can you review as soon as you are available? This is user 
issue that is already over a week old, so it needs your soonest attention. 
Roger, any ideas?

Original comment by da...@360-analytics.com on 16 Jan 2015 at 11:56

Attachments:

GoogleCodeExporter commented 9 years ago 
I tested a few more things. I still do not know why the baseline PVAV systems 
have enough heating capacity, but do not seem to use it to mitigate the UMLHs.

However, I updated this model to have the most recent changes to fix 
night-cycling/OA control (see attached idf for comparison to that attached in 
#2):
- Removed AirTerminal availability schedule
- Added availability schedule to Controller:MechanicalVentilation
- Revised Controller:OutdoorAir to BypassWhenWithinEconomizerLimits

These changes mitigate the heating UMLHs. However, these updates are not 
publicly released yet; they will be included in v3b. 

It is still unclear why the baseline heating system appears to have enough 
capacity, but is not controlled to meet the heating load. Kyle, if you are 
available to review today, your time would be much appreciated.

Original comment by da...@360-analytics.com on 19 Jan 2015 at 4:13

Attachments:

GoogleCodeExporter commented 9 years ago 
OK.  I'll go to work on it today.

Original comment by kbe...@gmail.com on 19 Jan 2015 at 4:17

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
For reference, attached are the cibd and SDD input XML files for the project 
that was used to generate the files attached in comment #2 using CBECC-Com v3 
(not current trunk source). 

I have tested this model using svn source current as of 1/19 and the baseline 
UMLHs are no longer present.

Original comment by da...@360-analytics.com on 20 Jan 2015 at 8:21

Attachments:

GoogleCodeExporter commented 9 years ago 
See my comments in the attached pdf.  I'm still not sure what is causing this.

Original comment by kbe...@gmail.com on 21 Jan 2015 at 5:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for reviewing Kyle. I agree with your observations. The reason for the 
UMLHs doesn't make a lot of sense to me and not sure why it is not an issue in 
other models. 

Yes, my understanding of Reverse action is that the heating coil output should 
be at the max when the air flow rate is at the heating max, but that doesn't 
appear to be happening. 

I will let the user know this baseline issue should be fixed in v3b, to be 
released towards the end of the month.

Original comment by da...@360-analytics.com on 21 Jan 2015 at 9:11

GoogleCodeExporter commented 9 years ago 
Just to pile on to my other comments in the pdf, not only is the terminal going 
up to max air flow before it has reached the coil heating limit (in terms of 
flow and temperature), it is jumping up there discontinuously as opposed to the 
smooth ramp you would expect from the documentation.  Something smells bad 
about the E+ control, but I'd rather not invest the time required to build a 
case unless this becomes widespread.

Original comment by kbe...@gmail.com on 21 Jan 2015 at 9:22

GoogleCodeExporter commented 9 years ago 
Sent the following message to user:

I apologize for how long it has taken me to follow-up on this issues. 

I can confirm that item #1) has been fixed in v3b, which is scheduled to be 
released around 2/1/15.  Unfortunately, there is no work-around for this issue 
in earlier versions.

In reviewing this model, I also noted a number of 'structural' issues with the 
HVAC descriptions in the model. These include:
- Some AirSystems have an AirSegment of Type = Exhaust, but currently these 
segments are only used in conjunction with AirSystem:Type = Exhaust.
- Many AirSegments have more than one child fan, heating coil, and/or cooling 
coil. Currently, each AirSegment can only have one of each of these components 
defined as child. The one exception is to have two coil heating objects if one 
is a supplemental heating coil for a system with a HeatPump coil.
- Some ThrmlZns are defined as Type = 'Unconditioned', yet they are specified 
to have VentSrc = 'Forced' and the VentSysRef has heating and/or cooling 
capacity. In this case, the zone should be classified as 'Conditioned'

If you are compiling rules and testing models with the latest (trunk) build 
committed to our online repo, you will find log file error messages describing 
these issues.

Original comment by da...@360-analytics.com on 25 Jan 2015 at 9:06