[Equest-users] eQuest importing mini-gude

[Nick Caton]

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

 

 

 

NICK CATON, E.I.T.

PROJECT ENGINEER

25501 west valley parkway

olathe ks 66061

direct 913 344.0036

fax 913 345.0617

Check out our new web-site @ www.smithboucher.com 

 

From: Pasha Korber-Gonzalez [mailto:pasha.pkconsulting at gmail.com] 
Sent: Tuesday, October 05, 2010 9:53 AM
To: Nick Caton
Cc: Jeremy Poling; eQUEST Users List
Subject: Re: [Equest-users] LEED-parking garage question/advice needed

 

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  :)

On Tue, Oct 5, 2010 at 10:31 AM, Nick Caton <ncaton at smithboucher.com> wrote:

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

 



 

NICK CATON, E.I.T.

PROJECT ENGINEER

25501 west valley parkway

olathe ks 66061

direct 913 344.0036

fax 913 345.0617

Check out our new web-site @ www.smithboucher.com <http://www.smithboucher.com>  

 

From: equest-users-bounces at lists.onebuilding.org [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Pasha Korber-Gonzalez
Sent: Tuesday, October 05, 2010 9:05 AM
To: Jeremy Poling
Cc: eQUEST Users List


Subject: Re: [Equest-users] LEED-parking garage question/advice needed

 

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

On Tue, Oct 5, 2010 at 9:53 AM, Jeremy Poling <jpoling at epsteinglobal.com> wrote:

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
Associate Vice President,

Senior Sustainability Analyst
Strategic Services
Site Solutions | Operations | Sustainability

EPSTEIN
Architecture
Interiors
Engineering
Construction

Epstein is a firm believer in sustainability. We ask that you please consider the environment before printing this e-mail.

 

From: equest-users-bounces at lists.onebuilding.org [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Walson, Kristy
Sent: Tuesday, October 05, 2010 8:21 AM
To: 'Pasha Korber-Gonzalez'; eQUEST Users List
Subject: Re: [Equest-users] LEED-parking garage question/advice needed

 

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

Mechanical Engineer / Sustainable Design

 

From: equest-users-bounces at lists.onebuilding.org [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Pasha Korber-Gonzalez
Sent: Tuesday, October 05, 2010 9:13 AM
To: eQUEST Users List
Subject: [Equest-users] LEED-parking garage question/advice needed

 

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 :)

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20101012/3c9127e5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1459 bytes
Desc: image001.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20101012/3c9127e5/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMPORT EXAMPLE.ZIP
Type: application/x-zip-compressed
Size: 117822 bytes
Desc: IMPORT EXAMPLE.ZIP
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20101012/3c9127e5/attachment.bin>