[Equest-users] eQUEST Calculations

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.html>
-------------- 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.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-0001.png>