[Equest-users] Saving Schedules to Library

[Pasha Korber-Gonzalez]

Yep--Nick, it is pretty cool and after you stepped me through the process
I've made use of the technique on several occasions, but (isn't there always
a 'but' in the way...)   As with the import location, this is what I can't
always trust through eQuest.  Like Paul had mentioned, if you need to have
your DOAS system higher on the navigation tree for the systems it is
serving, then you have to open the text editor.  no way around it.
which brings me to my personal point of dis-comfort---how can I be sure that
the location of the snippet i'm importing is always placed correctly in the
file for correct processing?  Do the utility schedules always know where to
jump in line when they get imported?

I guess since time is *always* an issue on energy models I usually choose
the path of input with the least risk, since I typically have no time to
lose on getting the models completed.

If you all are more trustworthy of eQuest, please share your experience and
help me learn to streamline my process even more.

thanks,
pkg

On Mon, Jun 13, 2011 at 11:25 AM, Nick Caton <ncaton at smithboucher.com>wrote:

>  The import function really is the cat’s meow ;).  It’s a great timesaver,
> even if you do need to break out your text editor (once only!).
>
>
>
> See attached thread from a while ago where I walk everyone through the
> process, and touch on the possibilities.
>
>
>
> Starting a personal collection of .inp snippets (schedules, equipment,
> constructions, and so on) is a major mile marker on the path to becoming a
> great eQuest modeler – welcome to the club =).
>
>
>
> ~Nick
>
> [image: cid:489575314 at 22072009-0ABB]**
>
> * *
>
> *NICK CATON, P.E.***
>
> SENIOR ENGINEER
>
>
>
> Smith & Boucher Engineers
>
> 25501 west valley parkway, suite 200
>
> olathe, ks 66061
>
> direct 913.344.0036
>
> fax 913.345.0617
>
> www.smithboucher.com* *
>
>
>
> *From:* equest-users-bounces at lists.onebuilding.org [mailto:
> equest-users-bounces at lists.onebuilding.org] *On Behalf Of *Paul Riemer
> *Sent:* Monday, June 13, 2011 12:07 PM
> *To:* 'Pasha Korber-Gonzalez'; Richard Auffermann
>
> *Cc:* equest-users at lists.onebuilding.org
> *Subject:* Re: [Equest-users] Saving Schedules to Library
>
>
>
> Collectively, we have previously suggested to create snippet text.inp files
> and then use the Import command rather than copy paste within a text editor.
>   So you might have a library of inp files for things like constructions,
> schedules, hourly reports, and utility rates (but you can reference saved
> ones within the wizard too).  Of course some things are order dependent like
> your OA source system being ahead of your destination system so if you want
> a DOAS snippet, you may need to manually place that within in the project
> .inp file.
>
>
>
> If you like having an inp snippet library then you might also try carrying
> the parametric run description (prd) file from project to project.
>
>
>
> *Paul Riemer, PE, LEED AP*
>
> *DUNHAM*
>
>
>
> *From:* equest-users-bounces at lists.onebuilding.org [mailto:
> equest-users-bounces at lists.onebuilding.org] *On Behalf Of *Pasha
> Korber-Gonzalez
> *Sent:* Monday, June 13, 2011 11:36 AM
> *To:* Richard Auffermann
> *Cc:* equest-users at lists.onebuilding.org
> *Subject:* Re: [Equest-users] Saving Schedules to Library
>
>
>
> At this point in time....Yes, that is the best that we can do as far as I
> know.   I had a client once who told me they were using, or pulling in thier
> own company's "library" data info, but I don't know if this was in the
> formal sense of using the Libraries in eQuest or if they created a seprate
> file that could be read by thier eQuest files to pull in the equipment info
> they wanted.
>
>
>
> The only way I know of and use right now is the copy paste method in the
> input file....
>
>
>
> Pasha
>
> On Mon, Jun 13, 2011 at 9:44 AM, Richard Auffermann <
> rauffermann at dagherengineering.com> wrote:
>
> I am generating schedules for my model and was hoping to save them so I do
> not have to recreate them all the time. There is an option to “Save to
> Library” but it is greyed out and cannot be selected. I looked in the
> archive and the only emails on this topic say that you can only save the
> text from the input file and copy this into new models. Is this the best we
> can do?
>
>
>
> Richard Auffermann
>
> Design Engineer
>
> DAGHER ENGINEERING, PLLC
>
> 29 Broadway, New York, NY 10006
>
> T. 212.480.2591 x122
>
> F. 212.480.2654
>
> rauffermann at dagherengineering.com
>
> www.dagherengineering.com
>
>
>
> Save Trees, Consider the Environment. Please print only when necessary.
>
>
>
> This email and any attachments may contain confidential or proprietary
> information and use or distribution is strictly prohibited. If you are not
> the intended recipient, please notify us and delete.  Dagher Engineering,
> PLLC has no responsibility for errors or discrepancies that may occur in the
> electronic transmission of data.
>
>
>
>
> _______________________________________________
> Equest-users mailing list
> http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org
> To unsubscribe from this mailing list send  a blank message to
> EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG
>
>
>
>
> ---------- Forwarded message ----------
> From: "Nick Caton" <ncaton at smithboucher.com>
> To: "Pasha Korber-Gonzalez" <pasha.pkconsulting at gmail.com>, "eQUEST Users
> List" <equest-users at lists.onebuilding.org>
> Date: Tue, 12 Oct 2010 15:32:17 -0500
> Subject: [Equest-users] eQuest importing mini-gude
>
> 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 hasunique 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
>
>
>
> [image: cid:489575314 at 22072009-0ABB]**
>
> * *
>
> *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
>
>
>
> [image: cid:489575314 at 22072009-0ABB]
>
> * *
>
> *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:* 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 :)
>
>
>
>
>
> _______________________________________________
> Equest-users mailing list
> http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org
> To unsubscribe from this mailing list send  a blank message to
> EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110613/8f251923/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1459 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110613/8f251923/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1459 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110613/8f251923/attachment-0001.jpeg>