[Equest-users] Baseline or Proposed? Chicken or the egg?

[Pasha Korber-Gonzalez]

Nick,

sometimes I think you state my thoughts better than I do, or maybe it's just
that we seem to think the same.  Great discussion.

Thanks to everyone who is contributing.

There are so many ways to create good, quality energy models.  The bottom
line key is that there is no right way, and there is no wrong way--though as
simulators we have to be responsible for all of our numbers & assumptions no
matter which order we input them to create our models.  If our results can
be supported and verified through pragmatic approaches and experience with
building design and energy use reference data, then we can feel more
confident that our models are in fact giving us a good (useful) 'glimpse' of
real life operation.


Pasha
On Wed, Oct 27, 2010 at 9:10 AM, Nick Caton <ncaton at smithboucher.com> wrote:

>  I’ve gone both ways over time and changed my mind a few times…  Here’s my
> current take:
>
>
>
> Whenever the proposed design is available for me to reference, I always
> prefer to start with the proposed model and then follow up with the
> baseline.  The main reason in my mind: the familiarity you gain with the
> proposed design (building/systems/loads and so on) by building that model
> first really streamlines the creation of a baseline model.  On the flip side
> and in my experience, starting with a baseline can sometimes require a lot
> of cross-referencing to ensure you define zoning patterns that will work for
> the proposed design systems.  Also, if and when you may need to calibrate
> the building loads/scheduling from the library defaults to match the
> proposed design systems’ anticipated values, it’s easier to calibrate one
> model and copy that work vs. calibrating two at once.  I personally find it
> annoying when I am juggling two open models and editing both when it could
> have been avoided.
>
>
>
> In a conceptual stage of new construction design, my “baseline models” are
> more often exploring a select few aspects of design at a time… and reporting
> modeled behavior in a relative sense against defined alternatives, not
> against a full-out 90.1 baseline.  It’s pretty hard to frame a response to a
> query during a conceptual stage about window materials as “you’ll get 3.2
> LEED points with Option A” when you don’t know the rest of the proposed
> systems/design – or even the building shape sometimes!   I much prefer to
> address such queries with relative gains, and advise what will tend towards
> a better final design.  The advantage to this approach is that time spent
> coming up with arbitrary guesses at final proposed/baseline performance can
> instead be spent helping guide the various parties towards an ideal final
> product in a quick fashion.  The disadvantage is we don’t typically know
> quite where the chips may fall until we are past the conceptual design
> stages, but my gut tells me you really can’t really know that until ink
> starts hitting paper, so to speak.
>
>
>
> 3.64’s LEED analysis feature is intended to streamline the process of
> creating a baseline from a proposed model, but it’s best summed as a
> “feature in progress.”  At best right now it creates a partial baseline
> model – with extra work required to wrap it up.  Be cautioned there are bugs
> in the current iteration of  this tool that may result in getting nothing
> for your efforts – don’t use this on a project with a tight deadline until
> you’ve tried it at least once.
>
>
>
> I would suggest creating your first model to cut your teeth on this feature
> from the 3.64 DD wizards.  3.63 models can be cranked through this tool, but
> they miss out on a good bit of the streamlining as they don’t have a variety
> of 90.1 compliance variables defined in the wizards – I’m not convinced
> large 3.63-based models really can save much time from this tool as a
> result.
>
>
>
> Outside of new construction or LEED, the term “baseline model” typically
> means something much different from the context of a 90.1 compliant building
> – it means what’s existing.  Those projects by contrast always involve
> building the baseline first in my experience.
>
>
>
> ~Nick
>
>
>
> [image: 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 *Paul Diglio
> *Sent:* Tuesday, October 26, 2010 10:25 PM
> *To:* Pasha Korber-Gonzalez
> *Cc:* eQUEST Users List
>
> *Subject:* Re: [Equest-users] Baseline or Proposed? Chicken or the egg?
>
>
>
> Pasha:
>
> I have not had the opportunity yet to create a model in 3.64.  I tried the
> 90.1 compliance on a few 3.63 projects and came up with all kinds of odd
> errors that I did not research.
>
> The models that I tried were very unusual, for example two sources of
> exhaust air and three sources of heating per zone.  Naturally, I had to
> fudge the systems to model a thermally equivalent mechanical system and work
> up exceptional calculations for GBCI.
>
> Perhaps the compliance works well with standard type systems.  Do you know
> if the compliance in 3.64 will accept a 3.63 project seamlessly?
>
> You might be correct that 3.64 is intended to create a baseline from the
> proposed.  My initial take was that the compliance tool would compare the
> baseline that I create to 90.1 specs and verify if I have modeled this
> correctly.
>
> What is your experience?  Can you create a baseline model from a unusual
> proposed model using the compliance tool?
>
> Paul Diglio
>
>
>
>
>  ------------------------------
>
> *From:* Pasha Korber-Gonzalez <pasha.pkconsulting at gmail.com>
> *To:* Paul Diglio <paul.diglio at sbcglobal.net>
> *Cc:* eQUEST Users List <equest-users at lists.onebuilding.org>
> *Sent:* Tue, October 26, 2010 11:06:44 PM
> *Subject:* Re: [Equest-users] Baseline or Proposed? Chicken or the egg?
>
> A couple of further questions then:
>
>
>
>    - if you are doing a LEED (or other) compliance model (without design
>    analysis) then do you build the proposed or baseline model first?
>    - With eQuest 3.64 doesn't it create a baseline model file based on
>    building your proposed model in eQuest first?  I thought that was the
>    function/convenience of the compliance tool.   Of course the baseline model
>    file needs to be checked and calibrated but the general intent was to
>    streamline the creation of a baseline model file in response to the inputs
>    for the proposed design.  Is this correct logic?
>
>  pkg
>
>
>
> On Tue, Oct 26, 2010 at 7:44 PM, Paul Diglio <paul.diglio at sbcglobal.net>
> wrote:
>
> Pasha:
>
> I always start with the baseline model because I am usually hired to
> provide design suggestions.  By modeling the baseline first I become
> familiar with the 90.1 requirements for the type of building and systems we
> are working on and I can make suggestions that will increase the efficiency
> of the facility above and beyond the 90.1 standard.
>
> For example, if my total exhaust air for a zone is less than 5,000 CFM,
> 90.1 does not require exhaust energy recovery, but by implementing this
> option in the proposed model we can achieve a greater reduction compared to
> the 90.1 baseline.
>
> Paul Diglio
>
>
>  ------------------------------
>
> *From:* Pasha Korber-Gonzalez <pasha.pkconsulting at gmail.com>
> *To:* eQUEST Users List <equest-users at lists.onebuilding.org>
> *Sent:* Tue, October 26, 2010 8:27:55 PM
>
>
> *Subject:* [Equest-users] Baseline or Proposed? Chicken or the egg?
>
>
>
> Out of curiosity do you build your proposed model first or your baseline
> model first?
>
>
>
>
>
> I build my proposed model first.  This is the way that I was taught and the
> way I learned that makes sense to me in terms of "backing-off" the
> performance values to that equal of the baseline values.  Or in the case of
> different types of HVAC systems I prefer to build the proposed model first
> and then do a "save as" to a baseline file to make all the appropriate
> baseline input adjustments.  This just seems most efficient for my modeling
> approach.
>
>
>
> What's your approach?
>
>
>
> pkg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20101027/1e70a5bb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1459 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20101027/1e70a5bb/attachment.jpeg>