I would like to put forth a list of improvements to eQUEST. I'm posting in just in off chance others might want to add and/or vote. (Marlin Addison in his classes always mentions that they need more user feedback for improvements).
1. The ability to create, leave out, or reassign keywords/components in parametric runs.
This would fix at least 2 things:
a. The glaring difficulty of creating 90.1 App G baselines when the proposed design has a chiller, but the baseline has packaged cooling. For me, this is the #1 shortcoming in eQUEST. Encountered all the time, tedious and error-prone every time.
b. Zones could be reassigned between runs.
Right now, we solve this by abandoning eQUEST before doing parametrics and using if-then statements in the INP and then using "case" type statements to change them in the BDL.
2. Fixing the spreadsheets so that they cut/paste can be used with Excel and Word, and so that multiple selections can be more easily edited at once. Also I think the spreadsheet locks cells when sorted sometimes.
3. A graphical and spreadsheet format for schedules in the detailed interface. Would streamline a tedious process and provide output for reports.
4. The ability to copy/paste components within the tree structure (right now have to use a pulldown menu to find the space).
5. A detailed interface zone/space editor that makes it easier to create, modify, or delete zones or spaces (not only helps w/updating the geometry, but for displacement ventilation too).
6. Updating the help menus to refer directly to eQUEST user inputs. Right now the DOE2 help will only tell you the keyword/command, but not where to find them in eQUEST's detailed interface.
7. Change the Zone Snap by CAD, Polygon, or Grid in the wizard to radio buttons instead of pulldown menus (I find it useful to switch between these somewhat often during zoning).
8. A feature to show if an entry is default, where it comes from (Title 24? DOE2? 90.1? 62.1? Standard practice?)
9. The ability to copy/paste parametric components and runs. Right now can be done in the .prd, but errors possible.
10. Azimuth field in the Window spreadsheet so that it can be sorted by orientation.
11. Several things are missing from the parametric run pulldowns (e.g. Tubular skylights, Lighting Control Method).
12. Making Savings by Design runs possible on the Baseline model, not just parametric runs.
-Eric
Great list!
One addition would be to fix the issue where roofs are created on lower
shells immediately below upper shells.
I agree, good list. This is more of an engine than an interface suggestion,
but creating:
1) a legitimate way to model UFAD systems and
2) water-water heat pumps would be extremely beneficial.
I know Trane is working on the former at least.
Anthony Hardman
I'm sure the eQuest user community could come up with an exhaustive list of
suggested improvements. Maybe the most useful way for the eQuest
development team to receive the suggestions would be through a wiki that
allows people to add to a list on-line instead of having to wade through a
long email chain, followed by a vote on the list of improvements so that a
ranking of most to least important improvements can be generated. Could
Scott or one of the other development team members chime in on this?
I don't have the web/programming skills to make such a thing happen, but
there are probably some folks on the list who do.
Steven Savich
I completely agree. Emails are not the way to keep track.Maybe if the discussion continues we'll see more progress, but right now, it seems pretty silent and interest is dying/dead for this topic. To me, this list is a priority.Almost everyone must encounter the same problems, but unless the developers know a lot of ppl want change "X", they only have anecdotal/sparse input and their own assumptions about what we need.I once suggested a website to track/vote, but don't think Hirsch et al. have the resource. For now, I'll keep a short spreadsheet tracking the bit of feedback so far (w/names).-Eric----------------------------------------------------------Steven Savich ssavich at systemswestengineers.com ( mailto:equest-users%40lists.onebuilding.org?Subject=Re%3A%20%5BEquest-users%5D%20Top%2010%20Improvements&In-Reply-To=%3C20080910154655.BF18548045%40diego.dreamhost.com%3E )I'm sure the eQuest user community could come up with an exhaustive list of suggested improvements. Maybe the most useful way for the eQuest development team to receive the suggestions would be through a wiki that allows people to add to a list on-line instead of having to wade through a long email chain, followed by a vote on the list of improvements so that a ranking of most to least important improvements can be generated. Could Scott or one of the other development team members chime in on this? I don't have the web/programming skills to make such a thing happen, but there are probably some folks on the list who do. Steven Steven Savich Systems West Engineers 411 High Street Eugene, OR 97401-2427 (541) 342-7210 (541) 342-7220 (fax) _____ From: equest-users-bounces at lists.onebuilding.org ( http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org )[mailto:equest-users-bounces at lists.onebuilding.org ( http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org )] On Behalf Of Anthony Hardman Sent: Wednesday, September 10, 2008 8:31 AM To: equest-users at lists.onebuilding.org ( http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org )Subject: Re: [Equest-users] Top 10 Improvements I agree, good list. This is more of an engine than an interface suggestion, but creating: 1) a legitimate way to model UFAD systems and 2) water-water heat pumps would be extremely beneficial. I know Trane is working on the former at least. Anthony Hardman
Another item to consider is the extensive amount of times the program
crashes. Today I am having trouble running anything more than a baseline
simulation (EEM's seem to crash the program more frequently).
GDS Associates, Inc.
In regards to program crashes..
I would not bet on anything right now except Version 3.61e (latest from
the DOE2.com download area). All who get these "souped up" beta versions
run the risk that the bugs have not been thoroughly flushed out.
Also make sure the input file you have are of the same vintage as the
version which you run. 3.61e files will NOT run on 3.61b.
Otherwise, like the flyers of old, blame "gremlins."
Somethings that I am facing right now -
1. Show on the interface U ? values (including outside film ) of
wall/roofs/fenestration which is easy to compare to what ASHRAE wants. Also,
when selecting glass from the library, if the usual values (U, SHGC, VT) can
be shown on the interface.
2. Show the % hours outside throttling zone for all parametric runs in
the Params.csv output file. This way one can see which parametric cases
have problems
3. Fix the electric sale values in the Params Mtr.csv file. Right now
if one has electric sale from PV, CHP, it shows up as -9999.
- Rohini
Hi All,
Assume a manufacturing / warehouse building has a very high process
load, say 50%-75% (or more) of total energy use. Must the energy model
reflect the actual load or can the simulation default to a process load
equal to 25% of baseline energy use? I can see the argument for each
strategy and would appreciate any insights or interpretations on this
issue.
This question relates exclusively to preparing energy simulation
documentation for a LEED project.
Many thanks,
Jeffrey G. Ross-Bain, PE, LEED
Jeff,
LEED requirements are that, to avoid having to supply supporting
documentation to the effect that process input is correct, the process
load be at least 25%. In your case, you are fine with your 50-75% (or
more).
______________
Demba Ndiaye