search

kbenne / cbecc

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

Compliance Margin and Standard Design end uses not displayed in T24 Compliance Analysis mode #444

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps reproduce the problem?
1. Run the 0400 Large Office Model in CZ6

What version of CBECC-NRes are you using? On what operating system?
v-1f(554)

Please provide any additional information below.

The model runs successfully in Title 24 Compliance mode, generates proposed 
model results and pdfs. However the Standard design end uses and Compliance 
margins are not displayed in the Results Summary screen and in the 
AnalysisResults-BEES.pdf. The same model runs fine displaying all results in 
CZ-1, 7 and 16. Attached are the screen shots and model files for CZ-6

Original issue reported on code.google.com by chitra.nbr on 6 Mar 2014 at 12:20

Attachments:

GoogleCodeExporter commented 9 years ago 
Please post the project log file - "<project filename>.log" for the errant run.
Thanks.

Original comment by scriswel...@gmail.com on 6 Mar 2014 at 12:57

GoogleCodeExporter commented 9 years ago 
Scott, please see attached

Original comment by chitra.nbr on 6 Mar 2014 at 6:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Scott, I see the same issue for CZ-15. See attached log file. Like I mentioned 
earlier the models run fine for CZ-1,7 and 16. The only difference between the 
models in each climate zone is the system sizes and of-course the weather file.

Original comment by chitra.nbr on 7 Mar 2014 at 6:25

Attachments:

GoogleCodeExporter commented 9 years ago 
A large number of ruleset updates were committed tonight (SVN rev #1561) that 
fix a number of "undefined data" rule evaluation errors, but there are still a 
number of other air- and water-side HVAC error messages that will require 
either/both ruleset or building input changes.
Passing ownership of this to Roger, but David will likely need to weight in as 
well.

Original comment by scriswel...@gmail.com on 9 Mar 2014 at 7:01

GoogleCodeExporter commented 9 years ago 
Attached is the latest version of the CZ-15 model that I reran after Scott's 
updates.

Original comment by chitra.nbr on 11 Mar 2014 at 9:50

Attachments:

GoogleCodeExporter commented 9 years ago 
Kyle and David, the baseline is throwing an EnergyPlus error: 
FindRootSimpleController: Root finder failed at PALM-SPRINGS-INTL ANN CLG 0.4% 
CONDNS DP=>MCDB, 00:00:00.0 - 00:15:00.0

I don't know what would cause this.  Kyle???

Original comment by rhedr...@archenergy.com on 11 Mar 2014 at 11:01

GoogleCodeExporter commented 9 years ago

Original comment by rhedr...@archenergy.com on 14 Mar 2014 at 4:06

GoogleCodeExporter commented 9 years ago

Original comment by rhedr...@archenergy.com on 14 Mar 2014 at 4:07

GoogleCodeExporter commented 9 years ago 
I could not reproduce this with the 040012-OffLrg-CECStd - b.xml model in the 
repository.  Can you post the 040015 xml and weather file?

Original comment by kbe...@gmail.com on 15 Mar 2014 at 4:30

GoogleCodeExporter commented 9 years ago

Original comment by rhedr...@archenergy.com on 15 Mar 2014 at 4:36

Attachments:

GoogleCodeExporter commented 9 years ago 
That was fast!  Roger I think you might have posted the weather file twice 
instead of the SDD file.

Original comment by kbe...@gmail.com on 15 Mar 2014 at 4:38

GoogleCodeExporter commented 9 years ago

Original comment by rhedr...@archenergy.com on 15 Mar 2014 at 6:08

Attachments:

GoogleCodeExporter commented 9 years ago 
I apologize this has taken me longer then expected.  I still do not have a 
detailed explanation of why there is trouble in this model.  I can say that in 
ARCATA I do not see fatal errors, but I do see ominous severe errors coming 
from the coil model.  I switched the model to "DetailedAnalysis" and the 
problem clears up in my autosized flavor of the 040015 model.

Original comment by kbe...@gmail.com on 17 Mar 2014 at 1:54

GoogleCodeExporter commented 9 years ago 
I reran the model with El-Centro weather file, CZ-15 and the simulation 
completed successfully. However issue persists with weather file Palm Springs 
Intl, CZ-15.

Original comment by chitra.nbr on 17 Mar 2014 at 11:04

GoogleCodeExporter commented 9 years ago 
Here are the things I have considered so far

timesteps per hour 8 
minimal set of design days
DetailedGeometry coil model for CoilCoolingWater.  This seems to work for my 
autosized version of 040015 b.  Please rerun / re hard size the b model through 
cbecc and see if the problem persists.
Looking at the impact of SizingSystem design humidity ratios.  We are currently 
using 0.008, which is a little under 50% rh at room temperature.  Trying to 
relax this a little.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 4:32

GoogleCodeExporter commented 9 years ago 
I am seeing a large difference in coil sizing when comparing my autosized model 
with detailed geometry to the hard sized model, also with detailed geometry, 
but with sizes based on old model.

Here is the autosized model with detailed geometry:

! <Water Cooling Coil Capacity Information>,Component Type,Name,Nominal Total 
Capacity {W},Nominal Sensible Capacity {W},Nominal Latent Capacity {W},Nominal 
Sensible Heat Ratio, Nominal Coil UA Value {W/C}, Nominal Coil Surface Area {m2}
Water Cooling Coil Capacity Information,Coil:Cooling:Water,BASESYS6 
COILCLG,156398.93,128910.30,27488.62,0.82,19420.08,196.97

Here is the hard sized model:

! <Water Cooling Coil Capacity Information>,Component Type,Name,Nominal Total 
Capacity {W},Nominal Sensible Capacity {W},Nominal Latent Capacity {W},Nominal 
Sensible Heat Ratio, Nominal Coil UA Value {W/C}, Nominal Coil Surface Area {m2}
Water Cooling Coil Capacity Information,Coil:Cooling:Water,BASESYS6 
COILCLG,308581.86,231920.09,76661.77,0.75,91993.63,933.05

The hard sized coil is much larger.  Presumably resulting in much lower 
sensible heat ratios and smaller design water flow rates which EnergyPlus is 
complaining about.

   ** Warning ** In calculating the design coil UA for Coil:Cooling:Water BASESYS6 COILCLG
   **   ~~~   ** the outlet chilled water design enthalpy is greater than the inlet air design enthalpy.
   **   ~~~   ** To correct this condition the design chilled water flow rate will be increased from 3.55288E-003
   **   ~~~   ** to 4.16852E-003 m3/s
   ** Warning ** In calculating the design coil UA for Coil:Cooling:Water BASESYS6 COILCLG
   **   ~~~   ** no apparatus dew-point can be found for the initial entering and leaving conditions;
   **   ~~~   ** the coil outlet design conditions will be changed to correct the problem.

Please rerun sizing routines with detailed model and I will make this 
comparison again.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 5:19

GoogleCodeExporter commented 9 years ago 
I'm running (now) the 040015 model attached to comment #5 with the most recent 
rules and OS code that includes the switch to "Detailed" coil model.  Will let 
you know what I find.

Original comment by da...@360-analytics.com on 19 Mar 2014 at 6:03

GoogleCodeExporter commented 9 years ago 
I just reran it as well, and got the same FindRootSimpleController: Root finder 
failed error that we saw previously.

Original comment by rhedr...@archenergy.com on 19 Mar 2014 at 6:10

GoogleCodeExporter commented 9 years ago 
Kyle, I just reran the 040015-Palm Springs and 040007-Carlsbad models both of 
which had baseline simulations aborting due to EPlus fatal errors.  I had not 
updated the cooling coil sizes as per your above comment as I just saw it. This 
time around the 040007 model ran successfully. However  040015 got error 
messages for Baseline Pumps. See screen shot attached. These errors appear 
different from the ones we were seeing until now. Since the 007 models runs 
fine maybe we are getting really close to solving Issue 444? I will re-size the 
coils and run the hard-sized models once again and post updates.

Original comment by chitra.nbr on 19 Mar 2014 at 6:28

Attachments:

GoogleCodeExporter commented 9 years ago 
After discussing the switch to detailed mode with some of my peers on our 
analysis side, I think we are in good standing with the change to detailed, 
regardless of the outcome on this issue.  They are using detailed mode 
exclusively for what sounds like similar issues.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 6:35

GoogleCodeExporter commented 9 years ago 
Can someone post the resized 040015 when they are done?  I would like to make 
the same comparison with E+ autosize.  Perhaps they don't need to match but 
they should be closer than they are.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 6:37

GoogleCodeExporter commented 9 years ago 
These are the files I just ran.  I used the AutoHardsize rules to size all the 
proposed HVAC capacities.  This one still got the FindRootSimpleController: 
Root finder failed error.

Original comment by rhedr...@archenergy.com on 19 Mar 2014 at 6:48

Attachments:

GoogleCodeExporter commented 9 years ago 
Attached are the files from the model Chitra submitted in comment #5 
(unchanged), using the most current rules/OS wrap. The -bz model does indeed 
use the water coil.  

If I compare the ratios CapTotGrossRtdSim values in the -bz and -b model, I 
find they are between 1.25 and 1.3. It seems reasonable that when E+ increases 
the design flow rate of BASESYS6 COILCLG, the capacity of the coil also goes 
up, which is my guess for the reason why you are seeing the large discrepancy 
between the autosize -bz caps and the -b hard-sized values in the eio file...

   ** Warning ** In calculating the design coil UA for Coil:Cooling:Water BASESYS6 COILCLG
   **   ~~~   ** the outlet chilled water design enthalpy is greater than the inlet air design enthalpy.
   **   ~~~   ** To correct this condition the design chilled water flow rate will be increased from 3.55288E-003
   **   ~~~   ** to 4.13611E-003 m3/s

I have a to switch to something else for an hour or two, so will be offline for 
a bit.  One thing to keep in mind is that the BASESYS6 COILCLG is part of a VAV 
system that serves one zone in the basement of the building. This atypical 
arrangement may be one component of the issue...

Original comment by da...@360-analytics.com on 19 Mar 2014 at 6:56

Attachments:

GoogleCodeExporter commented 9 years ago 
David, in Chitra's latest model, the baseline primary equipment CapRtd is set 
to zero, so there is not flow and the pump calcs blow up.  Not sure why the 
boiler, chiller and cooling tower all have CapRtd = 0.  The cooling and heating 
coils all seem to have non-zero capacities.

Original comment by rhedr...@archenergy.com on 19 Mar 2014 at 7:27

GoogleCodeExporter commented 9 years ago 
Capacity values of 0 in the baseline model most often stem from the bz 
simulation failing... 

We need to get organized on what models each of us are talking about.  I ran 
"Chitra's latest model" attached to this issue (as best I can tell attached in 
comment #5) and did not see the errors your are describing.  I suggest creating 
a google drive folder for this issue, with subfolders for each model that are 
named by both model name CBECC svn repo version.  Here is the list of files to 
include with each issue that I think will allow others to review fastest

cibd
SDD Sim XML
idf
err

Kyle, if you need referenced weather files, can you grab them from our repo?  
They are under CBECC-Com13/Data/EPW

Original comment by da...@360-analytics.com on 19 Mar 2014 at 7:54

GoogleCodeExporter commented 9 years ago 
yes to the weather file.  I realized they were in the repository after I asked 
for them.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 8:00

GoogleCodeExporter commented 9 years ago 
I have posted the requested files for three cases under the google 
drive/CBECC-Com Testing/Issue 444.

Original comment by rhedr...@archenergy.com on 19 Mar 2014 at 8:32

GoogleCodeExporter commented 9 years ago 
David, for the case where the pump errors occurred because b:CapRtd = 0 for 
primary equipment, the bz: run looks fine.  The EIO and HTML files all show 
capacities for the primary equipment.  I'm not sure where to go next with this. 
 Relevant files are in google drive/CBECC-Com Testing/Issue 444/Chitra with 
Pump Error.

Original comment by rhedr...@archenergy.com on 19 Mar 2014 at 9:21

GoogleCodeExporter commented 9 years ago 
I am currently experimenting with allowing the following Coil:Cooling:Water 
values to Autosize in the E+ simulations:
!- Design Inlet Air Temperature {C}
!- Design Outlet Air Temperature {C}
!- Design Inlet Air Humidity Ratio {kgWater/kgDryAir}
!- Design Outlet Air Humidity Ratio {kgWater/kgDryAir}

The idea here is that by setting these values (as we are now), we are setting 
up situations where the air conditions are not consistent with the other coil 
values that are currently hard-sized:
!- Design Water Flow Rate {m3/s}
!- Design Air Flow Rate {m3/s}
!- Design Inlet Water Temperature {C}
I think leaving these 3 properties hard-sized and allowing E+ to calculate the 
others still preserves the intent of "hard-sizing" a water coil.

Initial tests with the repo'd 040012 model indicate the sim runs fine and the 
Severe UA errors go away.  I am going to test chitra's original 3/18 run now, 
will report back here with results.

Original comment by da...@360-analytics.com on 19 Mar 2014 at 9:40

GoogleCodeExporter commented 9 years ago 
Re: #29.  Yes this sounds good.  This is why I always run autosize variations 
of your models.  But I am a little concerned that the hard size values that you 
are using have no impact on how the remaining autosize fields size out.  Maybe 
it doesn't matter.  I have a theory that if you autosize only what you are 
proposing the model simply looks at similar fields in the SystemSizing object.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 9:45

GoogleCodeExporter commented 9 years ago 
The values of 'Autosize' fields in any model are summarized in the 
ComponentSizing tables of the output file.  In the model I just run are listed 
below.  It looks like yes the outlet conditions are taken from SystemSizing, 
but the inlet conditions are (my best guess) iterated to to make the the 
culmination of inputs jive with eachother...

Coil:Cooling:Water

    Design Inlet Air Temperature [F]    Design Outlet Air Temperature [F]   Design Inlet Air Humidity Ratio     Design Outlet Air Humidity Ratio
BASESYS6 COILCLG    75.23   60.00   0.009032    0.008500
BASESYS6 COILCLG-2  75.30   55.00   0.008932    0.008500
BASESYS6 COILCLG-3  75.70   55.00   0.008871    0.008500
BASESYS6 COILCLG-4  75.70   55.00   0.008871    0.008500
BASESYS6 COILCLG-5  76.45   55.00   0.008891    0.008500

Still working on the test with Chitra's model, but guessing this will fix the 
issue.

Original comment by da...@360-analytics.com on 19 Mar 2014 at 9:54

GoogleCodeExporter commented 9 years ago 
May have been too over confident...  Also relaxed the System:Sizing humidity 
ratios by leaving these fields blank:
!- Central Cooling Design Supply Air Humidity Ratio {kgWater/kgDryAir}
!- Central Heating Design Supply Air Humidity Ratio {kgWater/kgDryAir}

However, still have severe error with Controller (FindRootSimpleController).  
Kyle, did you play with relaxing the Controller Convergence Tolerance {deltaC} 
or any of the other controller inputs?

Original comment by da...@360-analytics.com on 19 Mar 2014 at 10:02

GoogleCodeExporter commented 9 years ago 
I have not monkeyed with the humidity ratios yet, but note that leaving them 
blank will give you the E+ default 0.008.  I have sort of left that train of 
thought when I saw the large differences between the E+ autosize and the SDD 
provided hard sizes.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 10:15

GoogleCodeExporter commented 9 years ago 
That makes sense, though I am finding 0.008 worked and 0.0085 does not.

A few questions on the controller objects:
The !- Maximum Actuated Flow {m3/s} of the Coil:Cooling:Water objects does not 
sync with the coil !- Design Water Flow Rate {m3/s}. Can you describe where the 
controller value comes from, and confirm that the Coil:Cooling:Water flow rate 
is from the property CoilClg:FluidFlowRtDsgnSim?
The !- Minimum Actuated Flow {m3/s} of the Controller:WaterCoil objects are > 
zero, albiet very small.  Is there a reason for not setting this to 0?

Original comment by da...@360-analytics.com on 19 Mar 2014 at 10:30

GoogleCodeExporter commented 9 years ago 
Maximum actuated flow (on the controller) is 25% greater than "Design Water 
Flow Rate" on the coil.  Just a margin of safety which I don't believe is a 
problem, but not prepared to rule anything out.  Consider though that this 
seems to be a sizing problem, not an operation problem.  The design water flow 
rate is taken from the SDD property "FluidFlowRtDsgnSim."  The minimum flow is 
slightly off zero because I hold a suspicion that very small flow requests are 
triggering the (in some cases) very large pumps to blip on and do bad things.  
Like heat up the plant.

Original comment by kbe...@gmail.com on 19 Mar 2014 at 10:43

GoogleCodeExporter commented 9 years ago 
Here are my recommended changes to the OS translator for resolving this issue.

I've only tested these in the 040015 model Chitra provided in comment #5 (Palm 
Springs, Prim-Sec ChW pumping), and a modified version of the repo 040012-b 
model (Sacramento, primary-only ChW pumping); and they both successfully run.  
I do not see any issues with run away pumping or loop over-heating; I suspect 
that issue stemmed from a different issue of not setting the variable speed 
pump minimum flow to 0.

These changes apply to all models, even if HVACAutoSizing = 1 or 0.

Coil:Cooling:Water
!- Design Inlet Air Temperature {C} set to AutoSize
!- Design Outlet Air Temperature {C} set to AutoSize
!- Design Inlet Air Humidity Ratio {kgWater/kgDryAir} set to AutoSize
!- Design Outlet Air Humidity Ratio {kgWater/kgDryAir} set to AutoSize

Controller:WaterCoil (both heating and cooling coils)
!- Minimum Actuated Flow {m3/s} = 0

If you have other files that have failed with the FindRootSimpleController: 
Root finder failure, I ask you make these changes in your idf (ASAP) and test 
to see if it works, or send the file to me to test.

Future: should also do some testing of relaxing Coil:Heating:Water rated temps, 
but suggest we address that in a separate issue.

My files are uploaded to the GoogleDrive here:
https://drive.google.com/a/360-analytics.com/folderview?id=0B63Ndkzvj2l6R2xCZk5q
TEdvMFk&usp=sharing

Original comment by da...@360-analytics.com on 20 Mar 2014 at 12:14

GoogleCodeExporter commented 9 years ago 
Roger, did you resolve the problem you were having with with #28?  Let me know 
if you want me to take a look at it.  I'll be offline for a few hours, but 
could look at it tonight. If you want me to look at it, please point me to the 
model that is problematic.

Original comment by da...@360-analytics.com on 20 Mar 2014 at 12:20

GoogleCodeExporter commented 9 years ago

Original comment by chitra.nbr on 20 Mar 2014 at 12:31

GoogleCodeExporter commented 9 years ago 
David - re. 28, it appears to me that the primary equipment capacities were not 
being transferred back into the baseline.  I did not find a cause, but I don't 
really know what to look at for extracting results from EnergyPlus.

Original comment by rhedr...@archenergy.com on 20 Mar 2014 at 3:29

GoogleCodeExporter commented 9 years ago 
Committed @ r1616/1617 a fix to address Comment #28 of this issue .  The root 
cause is Proj:SimVarsInterval in the example project was set to 'Timestep' as 
opposed the default of 'Hourly'.  This causes the interval data be defined in 
the 'Timestep' category of the SQL database.  CBECC results retrieval of 
primary equipment peak loads relies on the interval data being present in the 
'Hourly' category of the db. To fix this, the BASELINESIZING rules always set 
bz:Proj:SimVarsInterval to 'Hourly', regardless of user input. Annual PROPOSED 
and BASELINE model interval results still are output at user specified interval.

Original comment by da...@360-analytics.com on 21 Mar 2014 at 2:59

GoogleCodeExporter commented 9 years ago 
I reran an autosized and hardsized versions of the model with v 1f 568 and both 
were successful. Changing status to done verified.

Original comment by chitra.nbr on 24 Mar 2014 at 9:41