search

kbenne / cbecc

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

5.4.5 Daylighting Control - Daylighting Control Requirements - condensed #854

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What NACM Section(s) are relevant to this issue?

5.4.5 Daylighting Control - Daylighting Control Requirements

Explanation of issue:

This issue combines issues 314 and 511, and recommends final language for the 
daylighting control requirements Building Descriptor, and adds new language to 
address daylighting controls requirements in parking garages.

Proposed resolution:
Attached language address daylighting control requirements in:
  - Residential Spaces
  - Parking Garages
  - Existing Buildings

as well as clarifying requirements or all other spaces.

Please provide any additional information below.

Original issue reported on code.google.com by lu...@360-analytics.com on 19 Nov 2014 at 6:32

Attachments:

GoogleCodeExporter commented 9 years ago 
This looks fine, and included in the current ACM language for v3a.

We could change the exception for the parking garage daylighting requirement to 
match the Standards, as you suggest. I would support that.

EXCEPTION 2 to Section 130.1(d)3: The total combined general lighting power in 
the primary sidelit
daylight zones is less than 60 watts.

Original comment by JohnJArent on 19 Nov 2014 at 10:25

GoogleCodeExporter commented 9 years ago 
The 'Input Restrictions' and 'Standard Design' portions of the language 
suggested in comment 1 above were adopted in ACM v4.4, however the 'Existing 
Buildings' portion was left out.  

Furthermore, ACM v4.5 seems to have reverted back to the original, which does 
not adequately represent requirements in residential spaces, parking garages, 
existing buildings or the proposed design. 

Updating status to 'Discussion' and priority to 'Critical'

Original comment by lu...@360-analytics.com on 5 Mar 2015 at 2:06

GoogleCodeExporter commented 9 years ago 
Lukas and team,

See a few minor comments and changes. In general I agree with everything Lukas 
proposed.  Personally I think we should not model DL in the parking garage, 
since it is mandatory, and since it is unnecessarily complex to model "daylight 
transition zones", "parking ramps" and parking garage geometry for this.  If we 
do model it, we could use the 60W threshold for parking garage lighting.

Thanks, John

Original comment by JohnJArent on 5 Mar 2015 at 6:33

Attachments:

GoogleCodeExporter commented 9 years ago 
I'll address the Parking Garage Daylighting Controls in this comment:

'Parking Garage Area Dedicated Ramps' and 'Parking Garage Area Daylight 
Transition Zones' are existing SpaceFunctions, so no complexity in excluding 
these spaces from the daylighting requirements, as long as they're modeled as 
separate spaces.  

Please keep in mind that the rules, as described in the suggested language are 
already in place, so from a development perspective, there is little utility in 
modifying the approach to reduce complexity.  

Note that I went with a 120W minimum threshold for parking garages, rather than 
60W to simplify the rules.  I would prefer to keep this simplification, unless 
the team has strong feelings otherwise.

Original comment by lu...@360-analytics.com on 5 Mar 2015 at 8:23

GoogleCodeExporter commented 9 years ago 
ddress John's comments on Daylighting Requirements for Existing Buildings (see 
word doc attached above) in this comment:

I agree with John's suggestion that increases in space area and/or window area 
WITHOUT modifications to the lighting system should not trigger daylighting 
requirements, and I believe this is consistent with the current rules.  

The current rule functionality is based on the following logic - developed 
between John and myself last may, and documented in Issue 511:

  - When lighting status is 'Existing' - control requirements same as Proposed
    Design
  - When lighting status in 'New' - control requirements same as for New 
    Construction
  - When lighting status is 'Altered'
     -IF installed LPD<=85% of standard design LPD: ctrl. req. same as Proposed
      Design
     -IF installed LPD>85% of standard design LPD: ctrl. req. same as New Const.

There is one major area where this approach deviates from the standards.  The 
decision on whether daylighting controls are required is based on the Space 
Status.  In cases where some lighting fixtures in a space are new or altered 
and some are existing, the standards say that the daylighting control 
requirements only apply to the New and Altered fixtures, but not to the 
existing fixtures.  The rules do not currently make this distiction - rather if 
ANY of the fixtures are new or altered, the daylighting control requirements 
are applied to the Entire Space.

Before refining the ACM language on Daylighting Control Requirements for 
Existing Buildings, I want to make sure that the above deviation is acceptable 
to the team.

Original comment by lu...@360-analytics.com on 5 Mar 2015 at 8:38

GoogleCodeExporter commented 9 years ago 
Lukas, thanks for the update. I think the area that deviates (how an alteration 
where only some fixtures are altered in a space) can be treated as we are 
handling it in CBECC-Com, since we do not want to track individual luminaires. 
Someone can always use a prescriptive approach for alterations as well.

I also wanted to see how this scenario would work:  if there is a space 
conversion from warehouse to retail, I want to see if the software allows for 
the user to define a NEW space type for the altered space, in which case the 
prescriptive/ App5.4A limits would apply for the retail space.

Original comment by JohnJArent on 5 Mar 2015 at 10:26

GoogleCodeExporter commented 9 years ago 
Thanks John,

Will you be drafting updated language to reflect the existing building 
daylighting requirements logic below?

With regard to your second question, I'm not sure I fully understand the 
scenario, but in my understanding - a change in occupancy type is treated like 
any other alteration.  The new/altered/existing status of each component is 
what triggers the baseline performance for that component.

Original comment by lukasho...@gmail.com on 6 Mar 2015 at 12:21