Heating/Cooling sizing assumptions

[GoogleCodeExporter]

What 90.1 PRM Section(s) are relevant to this issue?
3.2.3 Design Day Data
3.7.5.1 Total Cooling Capacity
3.8.1 Boiler Design Capacity

Explanation of issue:
Perhaps this has already been discussed and I missed the resolution, but 
thought I'd post to get confirmation:

This is not explicitly addressed in all the possible references to 
heating/cooling capacity, but at least in those listed above and as outlined in 
G3.1.2.2.1, sizing is to be performed using 1% DB/WB cooling and 99.6% heating 
design temperatures. The current example DDY files, and I presume others 
downloaded automatically from DOE server, include a number of design day 
conditions in addition to those in Appendix D.  

Proposed resolution:
Modify the DDY files to only include the two conditions identified in 
G3.1.2.2.1, or clarify in the PRMRM what additional design conditions and 
months (for solar orientation) may be used by software for sizing assuming they 
conform to ASHRAE HOF or some other reference.

Original issue reported on code.google.com by da...@360-analytics.com on 21 Oct 2014 at 3:08

[GoogleCodeExporter]

I think your first proposed solution is reasonable if you are able to do that. 

Original comment by bikerose...@gmail.com on 21 Oct 2014 at 8:35

[GoogleCodeExporter]

The first option can't be managed in rules, so adding Scott to this issue so he 
is aware of this.

With unedited DDY files, my guess is that is that it would not be that 
difficult to strip out the extra design days assuming the name of each 
SizingPeriod:DesignDay was consistent and could be used to determine which 
objects are removed. However, if the file is local and the user edits the 
object names, this method would not be that reliable.

Another approach is to add a SDD DesignDay object/properties which could be 
translated by OS.  The temps could be retrieved from a table version of 
Appendix D built into the tool. For simplicity/flexibility, probably best to 
just have the user specify the DD location separately from the other project 
data.

Please add other ideas here, but otherwise suggest we table this issue for 
discussion in the next conference call, 

Original comment by da...@360-analytics.com on 21 Oct 2014 at 8:54

• Changed state: Discussion

[GoogleCodeExporter]

I don't think editing the DDY files is practical, as we are downloading them as 
needed.  However, I think if we search for design days which include "Ann Clg 
1% Condns DB=>MWB" and "Ann Htg 99.6% Condns DB" in the name preceded by the 
station name, that will get the two days we want.  

Including monthly design days for additional solar angles will be difficult to 
do accurately.  I think we had these specially generated for T24 use.  They are 
not included in the standard DDY files downloaded from DOE.  I think the best 
we could do would be to use one of the included design days with an altered 
date, but that will overestimate the loads in intermediate months, although for 
California the monthly design drybulb temperature was only slightly less than 
the annual value for June through September.  for 

Original comment by rhedr...@archenergy.com on 22 Oct 2014 at 8:14

[GoogleCodeExporter]

The zipcode database we've sent uses ~850 of the total 1000+ TMY3 locations. 
The remaining 150 locations were removed due to incomplete DDY data. 
However, the project this was developed for uses "Ann Htg 99.6% Condns DB" and 
"Ann Clg .4% Condns DB=>MWB", so there might be some locations that could be 
missing "Ann Clg 1% Condns DB=>MWB".

I think I'm missing something here- why would we need monthly design days for 
additional solar angles?

Original comment by supriya....@pnnl.gov on 23 Oct 2014 at 6:05

[GoogleCodeExporter]

For CBECC, we included annual design days, but also some monthly design days 
for June through October.  These were included because of concerns that highly 
glazed building might actually have peak loads when the sun is lower in the sky 
and more directly incident on the walls and windows.  

We can use whichever design days we want, the point was to establish a uniform 
character string that can be used to identify specific design days to be used 
and exclude the others.  That character string is only one option.  

Original comment by rhedr...@archenergy.com on 23 Oct 2014 at 7:19

[GoogleCodeExporter]

ok, that makes sense. I agree that using the included design days with altered 
dates might overestimate loads. 
Looks like the only solution you have here is using 2 design days. 

Original comment by supriya....@pnnl.gov on 23 Oct 2014 at 7:44

[GoogleCodeExporter]

Switching owner to Scott to indicate if managing the 90.1 DDY files can be 
included in the scope of Phase 1.

Original comment by da...@360-analytics.com on 9 Dec 2014 at 10:11

[GoogleCodeExporter]

Original comment by da...@360-analytics.com on 9 Dec 2014 at 10:11