[Equest-users] eQuest Wiki & Other Question

[Matthew W. Higgins]

Thank you for your thoughts Bruce, Nick, and Carol.

I would like to be able to find a work flow, even similar to EnergyPlus and SketchUp, that allows for one building geometry model to be built then either export or import across various tools. Our company's situation would dictate these tools to be Trace and eQuest. Because eQuest is visually reassuring and less time intensive to build a model, it would be a huge time saver to take the eQuest energy model and export it to XML, which Trace can then import.

I'm like Nick, the few times that I've tried GreenBuilding Studio I've experienced unusable, or mangled results. And since it appears that GBS can go one way, Revit XML to eQuest INP, why can't it go the other way: INP to XML for Trane to be able to use. The biggest hurdle appears to be naming but should be a minor inconvenience (I think?).

If anyone has any ideas or is working  with this same workflow I'd appreciate your 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

www.bpce.com

From: Bruce Easterbrook [mailto:bruce5 at bellnet.ca]
Sent: Friday, July 16, 2010 3:48 PM
To: Nick Caton
Cc: Carol Gardner; Matthew W. Higgins; eQuest user forum
Subject: Re: [Equest-users] eQuest Wiki & Other Question

    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:image001.jpg at 01CB2717.51E93480]

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> [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<mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100719/91feea65/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1459 bytes
Desc: image001.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100719/91feea65/attachment-0002.jpg>