[Equest-users] eQUEST Calculations
Aaron Powers
caaronpowers at gmail.com
Mon May 21 17:30:14 PDT 2018
Very well put Nick, and an important perspective from the world where
savings projections are guaranteed. 2 + 2 = 4, but so does 10 - 6
On Mon, May 21, 2018 at 7:13 PM, Nicholas Caton via Equest-users <
equest-users at lists.onebuilding.org> wrote:
> As an energy engineer in the performance contracting side of the industry,
> a defining skillset for my job is creating and then calibrating models to
> fit historical utility data. We calibrate our models to a degree of rigor
> allowing our business to guarantee savings projected from those models (and
> write shortfall checks when we’re wrong). I don’t generally talk up my
> background, but I think in this case it helps to know where my voice is
> coming from to press a nuanced response:
>
>
>
> It's *possible* (again, not built-in) to automate iterative model input
> manipulation to “auto-tune” a building energy simulation to match a set of
> utility bills. You can even get the curves to fit extremely tightly over
> multiple meters. I’ve gone so far as to build some such tools from
> scratch, and that experience has taught me some very important lessons I
> didn’t set out to find. Among them, an “auto-tuned” model where many
> inputs are guided by randomization and computer logic can in practice
> become *very* difficult to trust for projecting savings, even on a
> relative “doesn’t need to be seen on the bills” level.
>
>
>
> On the other hand, if you careful to bound “auto-tuning” techniques to
> reasonable input ranges, and specifically to address “unknowable” model
> inputs which cannot be measured or reasonably estimated/inferred, the
> results can become much more useful, even enlightening. This “optimal”
> usage of the likes of monte carlo analysis, with and without machine
> learning algorithms, is anything but an “easy” button.
>
>
>
> I use doe2/eQuest as my primary energy simulation platform, however all of
> the above advice is platform-agnostic and holds true whether you’re
> crunching degree-day analyses in excel or wielding rooms of supercomputers
> in the cloud with e+.
>
>
>
> If calibration *matters*, and you’re not doing so just to tick some
> prescriptive box, best practice during model development is to keep mindful
> track of which inputs are:
>
> 1. *Known*
> 1. General Hierarchy of “Known:” Design/Construction Documents <
> As-Builts < RCx reports < Current field measurements & observations
> 2. Be mindful that construction documents and nameplate data are
> better than nothing, but commonly do not match reality and may be better
> considered as “informed estimates.” Allow some room for doubt.
> 2. *Estimated*
> 1. For existing buildings, this most inputs will be “estimated.”
> 2. If for example you have to define fan power based on scheduled
> static pressure loss and airflows on the drawings… that’s just aligning
> your estimate with the designer’s. Actual is probably something different.
> 3. Software defaults you understand are ready to “own” or explain
> fall under this category
> 4. This includes anything “auto-sized”
> 3. *Guesswork*
> 1. This includes software defaults that you are relying upon but
> haven’t yet investigated/understood.
> 2. This includes “known unknowns” for lack of information /
> resources.
> 3. A pretty common example is envelope constructions where (a) you
> have no architectural details/specifications to reference all the layers in
> the middle and (b) you aren’t budgeted/resourced to tear up a client’s
> walls to find out what’s inside.
>
>
>
> Considering the degree of input complexity for something like an eQuest
> model, I feel there will always be some blend of all if these input
> categories for every project and every individual modeler. Experience
> helps, though as the years pile on, for every new topic I get a lock on
> measuring/estimating, I feel like I learn about two more issues that were
> previously not on my radar… “the more I see the less I know!”
>
>
>
> Having rough estimates and unknowns is fine, but the more that you *know*
> or else can *reasonably estimate*, the better your initial calibration
> results will turn out, and the quicker the process of iteratively “tuning”
> a model will go. When you have a good record kept of which inputs are
> particularly solid vs. estimated/guesswork, you can work your way up the
> tree, marrying that knowledge to assumed/tested input sensitivity on the
> results, and plot a course to find your way back to the billed amounts!
>
>
>
> Hope this is helpful!
>
>
>
> ~Nick
>
>
>
> *Nick Caton, P.E., BEMP*
>
> Senior Energy Engineer
> Regional Energy Engineering Manager
>
> Energy and Sustainability Services
> Schneider Electric
>
> D 913.564.6361
> M 785.410.3317
> F 913.564.6380
> E nicholas.caton at schneider-electric.com
>
> 15200 Santa Fe Trail Drive
> Suite 204
> Lenexa, KS 66219
> United States
>
>
>
>
>
> *From:* Equest-users [mailto:equest-users-bounces at lists.onebuilding.org] *On
> Behalf Of *David Eldridge via Equest-users
> *Sent:* Saturday, May 19, 2018 2:08 PM
> *To:* equest-users at onebuilding.org
> *Subject:* Re: [Equest-users] eQUEST Calculations
>
>
>
> If you mean automatically adjusting the parameters of the model inputs to
> minimize error against the actual utility data by using a basis such as
> ASHRAE Guideline 14, then no eQUEST does not have that capability built in.
>
>
>
> You wouldn’t be changing the internal calculations – some review of the
> inputs and outputs should provide insight into what variables are known and
> which are assumed and may have a reasonable range of values resulting in a
> better fit to the utility data.
>
>
>
> With some on-site data such as what you’d be collecting for energy audits
> anyway, you can usually get an accurate model to start with, or with few
> iterations.
>
>
>
> There are other code/programs/platforms available that can help optimize,
> but requires a little more effort up front to either run the programming
> yourself or using a packaged program to setup the modeling files in a
> different program and tell the optimization program which variables have
> which range of values to be allowed.
>
>
>
> I hope this helps.
>
>
>
> David
>
>
>
>
>
> *David S. Eldridge, Jr., P.E., LEED AP BD+C, BEMP, BEAP, HBDP*
>
> Associate
>
>
>
> Direct: (847) 316-9224 | Mobile: (773) 490-5038
>
>
>
> *Grumman/Butkus Associates* | 820 Davis Street, Suite 300 | Evanston, IL
> 60201
>
> Energy Efficiency Consultants and Sustainable Design Engineers
>
>
>
> *grummanbutkus.com <http://grummanbutkus.com/>* | *Blog
> <http://grummanbutkus.com/blog>* | *Facebook
> <https://www.facebook.com/pages/GrummanButkus-Associates/1385285015032526>*
> | *Twitter <https://twitter.com/grummanbutkus>*
>
>
>
> *From:* Equest-users [mailto:equest-users-bounces at lists.onebuilding.org
> <equest-users-bounces at lists.onebuilding.org>] *On Behalf Of *Tom McGovern
> via Equest-users
> *Sent:* Friday, May 18, 2018 4:45 PM
> *To:* equest-users at lists.onebuilding.org
> *Subject:* Re: [Equest-users] eQUEST Calculations
>
>
>
> Hello,
>
>
>
> Have a question regarding the internal calculations performed by eQUEST.
> Am new to eQUEST and just looking to understand some basics. Trying to
> figure out if there is some way to modify internal eQUEST calculations so
> baseline model may be adjusted to fit existing utility bills or if there is
> no way to modify internal eQUEST calculations and we need various end
> arounds to fit baseline eQUEST model to fit existing utility bills.
>
>
>
> Thanks,
>
>
> Tom McGovern
>
>
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> ______________________________________________________________________
>
> _______________________________________________
> 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/20180521/a94e2ee5/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 255 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180521/a94e2ee5/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8477 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180521/a94e2ee5/attachment-0009.png>
More information about the Equest-users
mailing list