[Equest-users] eQuest Wiki & Other Question

[Varkie C Thomas]

Energy Programs are not used to design the project or select products.  They are used to analyze and compare options, make design decisions, and for code compliance and LEED certification.  During design, equipment is selected from performance data catalog and by using equipment selection programs.  All product manufacturers provide this.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100716/f445d5b0/attachment.htm>
-------------- next part --------------
     I just wanted to add my 2 cents worth on the Trace HAP issue and 
Nick's comment they should add compatibility to eQuest.  I fully agree 
they should.  More and more of my specifying work is required to be 
generic.  I refuse to pay either Carrier or Trane to use their program 
and do all their work for them.  Both programs are very good but they 
are basically an auto-size program for either Carrier or Trane 
products.  You have to admire the marketing aspect but with eQuest being 
a free generic program both companies have lost the war.  The specifying 
engineer pays good money to use their proprietary program, does all the 
work getting the project model built and working, sends the model to 
them, they press the button and the whole job is itemized and costed, 
they just have to fill out the bid forms.  The company which lost has to 
take the paper spec, build the model in their proprietary program, get 
it running and then output the job with their units.  I'm not sure how a 
lot of this works now as I'm mostly in the generic world but in decades 
past Trane and Carrier would battle to be the named manufacturer on a 
job.  There was major assistance from their engineers in doing the 
spec.  In recognition of the assistance, if you were willing to load 
their auto-size program for them you could/would receive a free seat.  
Your recognition for them is their name on the project units and the job 
input handed to them on a platter.  The downside of this system is both 
companies know each others units intimately.  Some jobs can be 
configured/manipulated to put the other company at a disadvantage, 
sometimes to the detriment of the owners system.  As software, eQuest 
does compete with HAP and Trace.  But the money for a modelling program 
pales compared the the real work of winning a job.  This is why both 
Trane and Carrier will give their program away free to their favourite 
specifying engineers.  They just off loaded a major part of the work to 
be able to bid a job.  Their major competitor is behind the 8 ball 
because they are starting from scratch to bid the job (and every other 
smaller company).  eQuest could actually make everyones job easier, 
maybe Carrier and Trane could throw some money or expertise into eQuest 
to help make it better and compatible with their programs.  The 
modelling job would only get done once, each company could take the file 
and convert it to their program, press the button and be ready to bid 
the job.  It would also get the owner a better job.  Both Carrier and 
Trane can easily check and tweak the job, probably provide some very 
good ideas to make the project better.  Face it both those companies 
have some major engineering horsepower, and can provide valuable input.  
They would lose a marketing device but in the end I believe it would 
save them a lot of money reworking jobs they didn't get the 
specification on.  Ultimately they would be able to bid more jobs, sell 
more units, make more money.  The customer would get a better system as 
well because money wasted on the dance could be applied to making the 
job better.  Equest could be made better faster with their help.  I 
think everyone would benefit.
Nice shot Carol :-) .
Bruce Easterbrook P.Eng.
Abode Engineering

On 16/07/2010 10:54 AM, Nick Caton wrote:
>
> Carol I think I can fill in a response:
>
> More often than not, big complicated energy modeling projects 
> typically result in another individual doing the HVAC design.  When 
> that other person regularly uses HAP and/or Trace to run sizing loads, 
> we ultimately have to butt heads to be sure eQuest is arriving at 
> similar answers, and it usually is off in one zone or another by a big 
> factor.  Quirks like unexpectedly huge people densities or particular 
> OA requirements get missed by eQuest's occupancy libraries.
>
> The concept of being able to get to a certain point of the energy 
> model, avoiding inputting any system sizing parameters (Auto-size 
> CFM's, capacities, etc), and then import such information from 
> another's work (rather than doing it by hand from cryptic output 
> reports), is really appealing as that's a part of the job that's both 
> un-fun and drawn out.  It does encourage using the model to tweak the 
> HVAC design process to a more intimate degree than we might otherwise, 
> once the two sets of results are calibrated to each other, which I 
> think is great.
>
> Envisioning this, I think it would manifest as an option in Trace or 
> HAP (or similar loads program) to  create a text file (*.inp) 
> containing the variables you'd want to import located under the 
> respective zones/systems.  There would have to be some graphic/visual 
> means of telling Trace/HAP the cryptic zone/system names generated by 
> eQuest to make this a time-efficient feature.
>
> To Matthew's question, I'm afraid this concept will be remaining in 
> perpetual la-la-land unless Trane or Carrier decide/realize they might 
> get a lot more business by assigning this interoperability feature to 
> their respective software developers.  As they both perceive their 
> software packages as "competitors," to eQuest, I don't see it 
> happening anytime soon, but I've been wrong before!
>
> I have heard scattered reports (and even seen a few screenshots) of 
> people in the "real world" managing to get GBS/Revit to interface via 
> export into eQuest -- but my personal attempts (3 times) have all 
> failed along the way... it seems rooted to model manipulations that 
> Revit MEP cannot do, which Architectural can (and we don't have the 
> budget for) that are required for a clean export.  To my limited 
> understanding, with this process you're getting geometries (polygons, 
> surfaces) defined, and possibly spaces/zones and constructions, but 
> beyond that you're left to do everything else without the wizards.
>
> ~Nick
>
> PS: If any man wants to contribute woman-hours (or vice versa, I won't 
> judge!) to making that eQuest-wiki concept happen, then make it known 
> =).  By contributing, I'm explicitly suggesting being willing to write 
> up one or more articles, mini-guides, or how-to's.
>
> 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 
> *Carol Gardner
> *Sent:* Thursday, July 15, 2010 10:05 PM
> *To:* Matthew W. Higgins
> *Cc:* eQuest user forum
> *Subject:* Re: [Equest-users] eQuest Wiki & Other Question
>
> Sorry, Matthew, but I can't resist this: if they were "woman-hours" at 
> stake there would be fewer and the outcome better. You left yourself 
> wide open for that one!
>
> Related to your second paragraph, can you give me an example of why 
> you would want to go from eQUEST to XML/Trace? I am stumped as to why 
> you want to do such a thing.
>
> Carol
>
> On Thu, Jul 15, 2010 at 1:51 PM, Matthew W. Higgins 
> <MWHiggins at bpce.com <mailto:MWHiggins at bpce.com>> wrote:
>
> Seems like a lot of the traffic lately (past month or so) could be 
> lightened by the eQuest Wiki that was mentioned. Anything come of 
> that? Of course, keeping respectful of the fact that these are 
> man-hours at stake to create it all.
>
> Also, unrelated, I'm aware of the workflow using GreenBuilding Studio 
> to go from Revit to eQuest and the ability to bring XML into Trace, 
> but is there a workflow to go from eQuest BDL to Trace or back out to 
> an XML, file then into Trace? Seems like GBS could go from eQuest to 
> XML/Trace, primarily for time savings when creating geometries.
>
> Thoughts? Thanks.
>
> Matthew Higgins, ASHRAE-HBDP, LEED-AP
>
> /Energy Engineer/
>
> * *
>
> *Bridgers & Paxton Consulting Engineers, Inc.*
>
> 4600-C Montgomery Blvd. NE
>
> Albuquerque, NM  87109
>
> 505-883-4111
>
> 505-888-1436  Fax
>
> mwhiggins at bpce.com <mailto:mwhiggins at bpce.com>
>
> *www.bpce.com <http://www.bpce.com>*
>
>
> _______________________________________________
> 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 
> <mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>
>
>
>
>
> -- 
> Carol Gardner PE
>
>
> _______________________________________________
> 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/20100716/f445d5b0/attachment-0001.htm>
-------------- next part --------------
_______________________________________________
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