<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Ralph, others,<br>
    <br>
    I think it all depends on the purpose of the simulation. Leaving
    aside the issue of design sizing for the moment, use of energy
    simulations to predict, or more often, match observed energy usage
    is typically concerned with annual or long-term energy usage.  In
    that case, stochastic variations around a mean doesn't provide much
    useful information, because the concern is not variability, but
    bias, in the results. It reminds me of when I saw that the
    uncertainty given for the modeled solar illuminance in the TMY2
    weather files was less than 3%. That seemed wrong to me, since I
    know that for any particular hour the differences between modeled
    and measured solar could be quite large.  However, when I read the
    documentation, it made sense because the uncertainty indicates not
    the stochastic variability, but the "mean bias error", i.e.,
    systematic variations, between the modeled and measured solar.  <br>
    <br>
    How does that relate to the value of stochastic modeling?  If we're
    only concerned in getting the annual totals to match, then whether
    or not we capture the stochastic variations from hour to hour seems
    to be minor importance.  I'm also having difficulties in understand
    what<br>
    additional information is output from "stochastic modeling", except
    having error bars on each hour, which undoubtedly will be large.<br>
    <br>
    My last comment is that although weather patterns are stochastic,
    the data on the weather files is quite deterministic, if we allow
    that the weather stations are doing a reasonably good job in
    measuring temperatures, wind speeds, etc.  The question of adding
    precision to the DOE-2 weather files is not an issue of stochastic
    behavior, but simply that of round-off errors.<br>
    <br>
    Joe<br>
    <pre class="moz-signature" cols="90">Joe Huang
White Box Technologies, Inc.
346 Rheem Blvd., Suite 108D
Moraga CA 94556
<a class="moz-txt-link-abbreviated" href="mailto:yjhuang@whiteboxtechnologies.com">yjhuang@whiteboxtechnologies.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.whiteboxtechnologies.com">www.whiteboxtechnologies.com</a>
(o) (925)388-0265
(c) (510)928-2683
"building energy simulations at your fingertips"
</pre>
    <br>
    On 7/27/2012 1:42 PM, Ralph Muehleisen wrote:
    <blockquote
cite="mid:CAA_BVWSAZjKG=B5OLUZAK9sae3qwkS9kVnzMMf7Sgnu=yLzTXg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div>Chris, Joe, others,</div>
      <div><br>
      </div>
      The dramatic effects of simply rounding off/ceiling the
      temperature data in weather files is a perfect example of why we
      need to, as an industry, move from deterministic energy
      predictions to stochastic energy predictions.  
      <div>
        <br>
      </div>
      <div>Weather and occupancy are inherently stochastic and when we
        couple that stochasticity with our uncertainty in so many of the
        actual building parameters (at least uncertainty as to their
        what their values will be when installed), it seems to me that
        far more meaningful energy predictions could be made using
        stochastic methods.  </div>
      <div><br>
      </div>
      <div>While you wouldn't necessarily want to use stochastic methods
        during much of the design iteration, stochastic estimation
        should be a standard procedure for comparing major iterations
        and for final energy predictions.  </div>
      <div><br>
      </div>
      <div>For all us researchers, there is plenty of work to be done in
        properly quantifying the stochasticity of weather, occupancy and
        other stochastic parameters and in developing uncertainty
        profiles for important parameters that are not stochastic.
         There is also opportunities for industry to develop the
        wrappers to take the info and create the DOE2 wrappers.</div>
      <div><br>
      </div>
      <div>Am I alone on this or do others feel the same way?</div>
      <div>
        <div><br>
          Ralph T Muehleisen<br>
          PhD, PE, LEED AP, INCE Board Certified, FASA<br>
          Principal Building Scientist<br>
          Argonne National Lab<br>
          9700 S. Cass Ave, Bldg 221<br>
          630-252-2547, <a moz-do-not-send="true"
            href="mailto:rmuehleisen@anl.gov">rmuehleisen@anl.gov</a><br>
          <br>
          <br>
          <br>
          <div>On Thu, Jul 26, 2012 at 2:31 PM, Joe Huang <span><<a
                moz-do-not-send="true"
                href="mailto:yjhuang@whiteboxtechnologies.com">yjhuang@whiteboxtechnologies.com</a>></span>
            wrote:<br>
            <blockquote>
              <div> Chris, others,<br>
                <br>
                Since as you've raised the question of how significant
                would be adding extra precision to the weather data in
                DOE-2, I was sent a copy of a recent paper by
                Annie-Claude Lachapelle of the Univ. of Calgary given at
                eSim Canada 2012 on this exact topic, "DOE2 Dry-Bulb
                Temperature Precision Level Impact on Sensible
                Economizer Performance".   With the author's permission,
                I've attached the paper with this post.  <br>
                <br>
                Joe<br>
                <pre>Joe Huang
White Box Technologies, Inc.
346 Rheem Blvd., Suite 108D
Moraga CA 94556
<a moz-do-not-send="true" href="mailto:yjhuang@whiteboxtechnologies.com">yjhuang@whiteboxtechnologies.com</a>
<a moz-do-not-send="true" href="http://www.whiteboxtechnologies.com">www.whiteboxtechnologies.com</a>
(o) <a moz-do-not-send="true" href="tel:%28925%29388-0265">(925)388-0265</a>
(c) <a moz-do-not-send="true" href="tel:%28510%29928-2683">(510)928-2683</a>
"building energy simulations at your fingertips"
</pre>
                <br>
                On 7/25/2012 10:45 AM, Joe Huang wrote:
                <blockquote type="cite">Chris, <br>
                  <br>
                  My attention on this issue was first raised about 15
                  years ago when I was working with non-US weather data
                  , i.e., the rest of the world, that are all reported
                  in 0.1 C. I've noticed since that US stations have
                  also moved to the use of metric units, i.e., 0.1 C for
                  temperature. The DOE-2 weather format is still in
                  integer F, which leads to three unfortunate effects:
                  (a) hourly records can be off by as much as 0.5 F, (b)
                  clumping of the temperature distribution, and (c)
                  statistics such as degree-days will be off by a
                  percent or two compared to the original data. Now, one
                  can say that all this is immaterial in the bigger
                  picture of things, which has been the default attitude
                  so far, but since it's really quite simple to fix, why
                  not get it right, i.e., doesn't it feel much better to
                  see the same temperatures in the DOE-2 outputs as in
                  the original weather data? <br>
                  <br>
                  BTW, all the weather data that I've looked at are
                  records of conditions on the hour, not the average
                  over the hour, except for solar radiation. <br>
                  <br>
                  Joe <br>
                  <br>
                  <br>
                  On 7/25/2012 9:53 AM, Chris Jones wrote: <br>
                  <blockquote type="cite">Joe <br>
                    Given that the time steps are an hour, and the fact
                    that weather data is averaged over an hour, plus the
                    fact that the building local will have variations
                    from the weather station local, would an extra
                    decimal point provide more useful information? <br>
                    <br>
                    <br>
                    At 07:43 AM 25/07/2012, Joe Huang wrote: <br>
                    <blockquote type="cite">This is not possible at
                      present without changing the DOE-2.2 source code
                      to read a weather input file with decimal values.
                      When DOE-2 was first designed in the early 1980's,
                      memory was a big concern, so the weather data was
                      reduced to integers and then packed, which is why
                      the DOE-2 *.BIN file is so small (146K). I have
                      actually developed a modified file format for
                      *.BIN where I save an extra digit of precision,
                      i.e., temperatures to 0.1F instead of 1 F, but the
                      source code would also need to be changed slightly
                      to read this extra information. I've mentioned
                      this to the developer of eQUEST/DOE-2.2 and will
                      be experimenting with making this change to the
                      source code. If and when it's proven to work and
                      gets incorporated into DOE-2.2, I'll let everyone
                      know. I welcome anyone who thinks this is a useful
                      modification to send me an e-mail. It might spur
                      me on to do something! Joe On 7/23/2012 2:44 AM,
                      è”¡æ˜€èŠ wrote: > Hi, everyone: > > We
                      know that eQUEST can edit personal weather data.
                      > But the dry-bulb and wet-bulb temperature in
                      weather data can only > enter integers. > Is
                      it possible to have more precise temperature to
                      decimal place? > Thank you very much. > >
                      >
                      _______________________________________________
                      > Equest-users mailing list > <a
                        moz-do-not-send="true"
href="http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org">http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org</a>
                      > To unsubscribe from this mailing list send a
                      blank message to > <a moz-do-not-send="true"
                        href="mailto:EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG">EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG</a>
                      > -- Joe Huang White Box Technologies, Inc. 346
                      Rheem Blvd., Suite 108D Moraga, CA 94556 (o) <a
                        moz-do-not-send="true"
                        href="tel:%28925%29388-0265">(925)388-0265</a>
                      (c) <a moz-do-not-send="true"
                        href="tel:%28510%29928-2683">(510)928-2683</a> <a
                        moz-do-not-send="true"
                        href="http://www.whiteboxtechnologies.com">www.whiteboxtechnologies.com</a>
                      "Building energy simulations at your fingertips"
                      _______________________________________________
                      Equest-users mailing list <a
                        moz-do-not-send="true"
href="http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org">http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org</a>
                      To unsubscribe from this mailing list send a blank
                      message to <a moz-do-not-send="true"
                        href="mailto:EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG">EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG</a>
                      </x-flowed> <br>
                    </blockquote>
                    <br>
                    >> <br>
                    Christopher Jones, P.Eng. <br>
                    Suite 1801, 1 Yonge Street <br>
                    Toronto, ON M5E1W7 <br>
                    Tel. <a moz-do-not-send="true"
                      href="tel:416-203-7465">416-203-7465</a> <br>
                    Fax. <a moz-do-not-send="true"
                      href="tel:416-946-1005">416-946-1005</a> <br>
                    email <a moz-do-not-send="true"
                      href="mailto:cj@enersave.ca">cj@enersave.ca</a> <br>
                    <br>
                    <br>
                  </blockquote>
                  <br>
                  <br>
                  <pre>  
_______________________________________________
Equest-users mailing list
<a moz-do-not-send="true" href="http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org">http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org</a>
To unsubscribe from this mailing list send  a blank message to <a moz-do-not-send="true" href="mailto:EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG">EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG</a>
</pre>
                </blockquote>
              </div>
              <br>
              _______________________________________________<br>
              Equest-users mailing list<br>
              <a moz-do-not-send="true"
href="http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org">http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org</a><br>
              To unsubscribe from this mailing list send  a blank
              message to <a moz-do-not-send="true"
                href="mailto:EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG">EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG</a><br>
              <br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
  </body>
</html>