Hi,
I would like to get a few opinions from some fellow simulators on a modeling
approach for a LEED project. Please share your opinion/advice if you are
interested.
Project: Four separate buildings that surround an open-air parking garage
structure (all above grade.)--Location is Miami, FL
Intent: All Four buildings (as a whole project) are going for LEED
certification. Each building will be modeled in it's own .pd2 file as the
simulator would prefer to manage the models in this manner versus using a
campus modeling approach in a single .pd2 file.
USGBC recommendations where that the parking garage should be divided (or
split) into four pieces and 1/4 of the parking garage should be included
with the buildings in each of the separate model files.
The ISSUE is this: My simulation gut instinct is telling me that this is a
really bad way to include the energy use of a parking garage in a project
model....(I was actually shocked that this was the advice from a LEED
representative.) So I am trying to advise my colleague that it might be
better to not include the actual parking structure (i.e. separate shell) in
each model, but to calculate the lighting use (on a schedule of operation)
for the parking garage lighting and then simply add in that energy as a kW
input on a separate meter and assign a ltg operating schedule to it. With
this approach it would be easier to take the advice of the LEED folks and
input 1/4 of the installed kW in each of the separate model files, rather
than wasting time with building in (& managing) another shell in each model
file. (FYI-there are no other ECM's that will be accounted for in the
parking garage.)
What do you think of this approach? Do you think that it is significant
and important to include the "physical" presence of the parking garage in
each of the model files? What approach would you take?
Thanks for your time as always...
Pasha :)
Hi Pasha,
Having modeled a few parking garages in various software at this point, I also do not agree with the LEED representative's suggestion. In my experience, parking garages typically have daylighting controls to turn off perimeter lights during the day. This would be tough for a simulation program to model without creating a separate building for the parking garage. I know you said that the parking garage would not be utilizing any ECM's, but I like to leave my options open in case an owner comes back and decides that the payback is well worth the money spent up-front for controls.
If you end up incorporating the lighting as a bulk load on the electrical meter at each building, just remember that you'll need 2 bulk loads - one for daytime garage lighting and one for night time exterior lighting. If you're sure they won't be adding ECM's at a later date, then I think the bulk load idea will work. Just be sure to spend some time on your lighting schedule because the lighting savings seen between the baseline and proposed models for a parking garage can be significant and you don't want to lose any of this benefit. Good luck!
Kristy Walson, PE, LEED AP
As a note, the USGBC reviewer's advice is in line with the requirements
of Energy Star for detached buildings on a campus with shared parking:
for separate buildings on a campus, the parking area (surface and/or
garage) must be divided between the buildings when entered into
Portfolio Manager. If this is a LEED 2009 project and the owner plans
to comply with the 5-year metering requirement via Energy Star, setting
up the model in that manner will make it consistent with the mandatory
minimum M&V requirements. I'm not sure what led to the decision to
model each building in a separate PD2 file (other than scheduling of the
design work meaning Building 4's model won't be needed for some time
after Building 1's model is done), but it might provide some benefit to
model the campus in one file. I would think this would be true in 2
specific cases:
- If there is a single meter covering all campus electrical use
(not uncommon for campuses), allowing the model to calculate a
coincident demand for cost purposes that might be lower than the sum of
the demands for the four separate model
- Credit for daylighting is being pursued and there is a
potential for one of the buildings to shade another, making the combined
model file more conservative on energy savings from daylighting than the
four individual models
I have done a split PD2 file approach on a model before and while it
made sense when it was setup and the project was small (10K SF total),
responding to comments was more difficult. For example, if there was
some error in the baseline U-Value then each model file would have to be
corrected individually instead of changing the wall type in a single
model (4 changes instead of 1). Just some thoughts to consider.
I would partially agree with the reviewer, though - the parking garage
needs to be part of the model and with a split model you would have to
put the parking garage into each of the four models. I probably would
have taken a slightly different approach, though - If the campus is not
modeled in a single model, the parking garage should be modeled on its
own, with the resulting energy divided between the four models
proportionate to the number of spaces allocated to each building or the
proposed occupancy of each building, since those are the factors that
determine how much of the garage each building would use.
JEREMY R. POLING, PE, LEED AP
Thanks Jeremy,
I wasn't aware of the 5-year metering requirement for Energy Star...that
does help me 'accept' the advice for the model a bit more. However, it
still doesn't sit right with me to split a buiding amongst several model
files for the same reason that you mentioned about disproportionate sim
results.
I liked your observations for the finished model--thanks for sharing your
experience on that. I also like the idea of doing a separate model for the
garage itself with the approach of keeping all the models in separate files,
but I think I will have to reconsider the multi-files approach versus
inputting all 5 structures into one model file. hmmmm......
pkg
A few extra thoughts,
In line with Jeremy's suggestion regarding a campus model being a useful
approach... Perhaps you can have your cake and eat it too?
The new (3.64) wizard screens have a new input field for each shell that
allow you to assign custom prefixes suffixes to each shell - if you
utilize this while making separate files (prefix each group of shells
with N#,E#,S#, W#), and make a point to define your geometries from a
holistic CAD reference, I'll bet you can end up with 4 distinct files
that will all import cleanly into each other when all's said and done as
a final step... you'd want to continue the nomenclature when defining
things in detailed mode of course.
I haven't submitted but one garage for LEED, but I'm of the opinion any
unconditioned garage isn't anything more complicated than a collection
of building shades and/or process / external lighting loads to an eQuest
modeler! To Kristy's cautions, one can easily define multiple exterior
lighting loads (up to 10 I think) - with distinct magnitudes and/or
scheduling... allowing you to model interior/perimeter and
daytime/nighttime controls. Photocell scheduling functions are
available for perimeter lighting as well.
Pasha, it'll ultimately come down to how you want to move forward, but 4
separate models sounds like it might work for you: Each would feature
distinct component prefixes and building shades mimicking the entire
garage, but external lighting/process loads representing a quarter of
the garage. When the time comes that a campus model is desireable for
whatever reason, you can delete the garage-shades in models 2,3 and 4,
and import into #1, then modify your exterior loads to ensure you're
modeling the full garage.
If you desire extra accuracy in the separate models, you may want to
consider creating some building shades to represent the other 3
buildings - but you'd want to delete those later when importing the
files together for a campus model...
NICK CATON, E.I.T.
Hi Nick,
I can't remember how long you've been modeling, but your advice exudes
'knowledge beyond your years.' At least from my perspective, I didn't
think I could have it a win-win situation for this project, but I like your
approach.
Also, thanks for pointing out the idea of garages being nothing more than
building shades & process/ltg loads I hadn't thought of inputting the
"idea" of the garage as building shades. :)
Importing the separate models into one later on seems daunting & tedious,
but with the separate-to-one approach I guess it can always be an option
that I decide later if it seems necessary, or for comparative purposes & a
chance at a sensitivity analysis...
I always appreciate the multitude of intelligent answers and supportive
comments from fellow simulators on this list. Now we can keep moving
forward until the next hurdle.
Thanks,
Pasha :)
Hi Pasha,
I would put all 4 buildings and the garage into one model. As Jeremy pointed
out doing so would take care of any metering and shading issues. The only
downside I can think of is the size of the model, which might add to the run
time. Since eQ is so fast, however, it's a difference of 2 minutes vs 30
seconds, just enough time to grab another cup of coffee or to let the dogs
out.
Best,
Carol
To anyone who hasn't explored the eQuest import function yet - You gotta try this!
This oft-overlooked feature is a huge timesaver, and can make cutting in work from previous projects a breeze once you've wrapped your mind around the concept. I've made and attached 2 quick example files to walk anyone through it:
1. Unzip the example projects I've attached.
2. Open either the WEST project or the EAST project.
3. Switch to detailed edit mode if I forgot to save it that way (oops!) - a good point though: you can't do this until after the wizards.
4. Click File ? Import File...
5. Browse to and select the other project's .inp file (EAST or WEST)
6. Follow the dialogues - eQuest will check for identically named items so as not to overwrite anything without your explicit knowledge.
Special note: In these quick examples, I used the new (as of eQuest version 3.64) prefix functions in the wizards to ensure each project has unique and easily identifiable component names starting with WST or EST, so there should be zero conflicts.
7. Check out the 3D view tab - your project now includes both buildings!
8. Check out the component tree and notice how everything is clearly organized as staring with either EST or WST
If you should ever create a custom schedule/system/construction/etc. that you'd like to import into future projects, or if you want to draw something from a past project, isolate that work in the source-project's .inp file, save that text as a new, smaller .inp file, and you're ready to import! When importing, eQuest will organize all components into the same sections of the target-project's .inp file, so don't worry about keeping everything in perfect order in your "snippet" .inp's. Just remember to retain everything up to the ".." after each component. It's also advisable to rename any saved components like this with some kind of unique/identifiable name to avoid "same-name" conflicts during import.
There you have it! Go forth and start a reference library of things you'll use more than once if you haven't already! If you're in a pay-it-forward mood, consider sharing any gems with the group at large - it's a great way to make friends ;).
Ciao,
NICK CATON, E.I.T.