[Equest-users] The value of monthly peak demand is not consistent in two different energy simulation report.

Tue Mar 5 09:34:49 PST 2019

Hi Nitin,

Quick answer: ES-E is expected to reflect demand measurements which account for the DEMAND-INTERVAL specified (or defaulted: 15 minutes in the case of electrical meters & 1 hr in the case of all others).  These will generally be higher than demands reported elsewhere in the simulation outputs.

Teaching a man to fish, you could figure this out by:

  1.  Reviewing the annotations provided for both detailed simulation reports under Help --> Tutorials and Reference --> Detailed Simulation Reports Summary (pdf)

[cid:image003.png at 01D4D344.8A869660]

  1.  Reviewing the associated doe2 reference manual entries for the rate DEMAND-INTERVAL and related inputs, by right clicking them

[cid:image005.png at 01D4D345.82055A20]

In case this isn’t intuitive…

  1.  You can read a fair analogy regarding how demand intervals work in the real world here: https://www.northwesternenergy.com/docs/default-source/documents/E-Programs/E-demandcharges.pdf
  2.  By way of further explanation/example, you can make ES-E report demand each month to match what’s shown in the other SIM reports by specifying a 60 minute DEMAND-INTERVAL for your custom rate (which appears to have two uniform blocks), as illustrated here:
[cid:image004.png at 01D4D344.8A869660]

You can leverage that input more purposefully to have ES-E reflect daily peaks, or sub-hourly measurements of a different resolution.

Finally, and because demand outputs from doe2/eQuest is fairly stated a minefield of potential misinterpretation, I’ve copied a “guide” I put together some time ago for further reading (to satiate any further interest that may be remaining 😉).  It breaks down a series of additional means by which monthly demand can be read from different reports/outputs, to different ends.

Some might also be wondering (as I did) what exactly eQuest is calculating at a sub-hourly resolution to make these inputs meaningful in the first place.  It turns out a helpful fellow (me) wrote up his findings on that matter and I’ve copied that info below as well.

Sorry Nitin… this email just became really big =/…  Hope some of this is helpful however!

~Nick

[cid:image001.png at 01D4D342.4D1AEEE0]
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<mailto:nicholas.caton at schneider-electric.com>

15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219
United States

[cid:image002.png at 01D4D342.4D1AEEE0]

From: Equest-users <equest-users-bounces at lists.onebuilding.org> On Behalf Of Nitin Harjai via Equest-users
Sent: Tuesday, March 05, 2019 9:19 AM
To: equest-users at lists.onebuilding.org
Subject: [Equest-users] The value of monthly peak demand is not consistent in two different energy simulation report.

[External email: Use caution with links and attachments]

________________________________

Hi,

I am working on the energy model using eQuest 3.65 and the project is based in Down town Washington DC. I have used the weather file nearest to the project location i.e., Maryland.

I am having the situation where I don't understand that, after the simulation done the peak demand (kW) value of particular month in the energy simulation report ES-S is not matching with the value of same in the another energy simulation report PS-B from the same model.

Please advise on where I could be wrong because of that I am getting the different peak demand (kW) value of particular month in two different reports (ES-S & PS-B).

Kindly find the attached pics highlighting the different peak demand of same month in two different reports (ES-S & PS-B).

Thank you for your time and hoping to hear immediate response to this matter.

Regrads,
Nitin J Harjai

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

From: Equest-users <equest-users-bounces at lists.onebuilding.org> On Behalf Of Nicholas Caton via Equest-users
Sent: Tuesday, March 28, 2017 8:29 AM
To: Lapierre, Patrick <plapierre at bpa.ca>
Cc: 'equest-users' <equest-users at lists.onebuilding.org>
Subject: Re: [Equest-users] Subhour demand metering

Looks like eQUEST will, with specific airside system types (not all:  SZRH, VAVS, RHFS, HP, CBVAV, PSZ, PVAVS, PTAC, and PVVT) and for electric meters only, determine the coincident sub-hourly peak draw for those systems’ central/zonal components (compressor/fans/reheat/baseboards/etc), and layer that on top of the remaining hourly consumptions determined elsewhere in the model (plant loads, lighting, etc).  This “modified” peak which isn’t quite the results of a sub-hourly timestep throughout the model is reported as “billing demand” and as a result can report higher than “metered demand.”

Electric rates default to a 15 minute interval, but you can adjust that up/down.

For non-electric utilities, you can set up a daily interval for a peak-day rate structure by entering a number >60 for the interval.

Further reading at:

  *   Volume 3: Topics > Central Plant Components > ELEC-METER SUB-HOUR Demand Intervals
  *   Volume 2: Dictionary > Economic Components > UTILITY-RATE > Energy and Demand Charges > DEMAND-INTERVAL
  *   Volume 2: Dictionary > Economic Components > UTILITY-RATE > Energy and Demand Charges > DEMAND-WINDOW
  *   Special Highlight:  See markups for report ES-E in Help -->  Tutorials and Reference --> Detailed Simulation Reports Summary
[cid:image006.png at 01D4D347.608BCB20]
[cid:image007.png at 01D4D347.608BCB20]
[cid:image001.png at 01D4D342.4D1AEEE0]
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<mailto:nicholas.caton at schneider-electric.com>

15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219
United States

[cid:image002.png at 01D4D342.4D1AEEE0]

From: Equest-users [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Lapierre, Patrick via Equest-users
Sent: Monday, March 27, 2017 1:55 PM
To: equest-users at lists.onebuilding.org<mailto:equest-users at lists.onebuilding.org>
Subject: [Equest-users] Subhour demand metering

Hello everyone,

I’ve got a project on my hand in which the electrical demand reported in the PS-E report doesn’t match the billing demand in the ES-E report.
I’ve found that this was due to the “demand interval” of 15 mins on the utility meter. Fixing the demand interval to 60 mins solved the matching demand problem between the PS-E and ES-E report.

I’m just curious as how does eQUEST calculate subhour demand and determined that some electric heating power in my building didn’t last more than 15min.
I need a captain here. Anyone can enlighten me?

Thanks,

  [Bouthillette Parizeau] <http://www.bpa.ca/>

Patrick Lapierre_ing.
plapierre at bpa.ca<mailto:plapierre at bpa.ca>   |  www.bpa.ca<http://www.bpa.ca>  |  t: 5143833747x2807

Les informations contenues dans le courriel que vous venez de recevoir, y compris les pièces jointes, sont destinées à l’usage exclusif de la (ou des) personne(s) identifiée(s) comme destinataires et sont confidentielles. Si vous n’en êtes pas le destinataire, soyez avisé que tout usage en est interdit. Si vous avez reçu ce courriel par erreur, veuillez le retourner à l’expéditeur et le supprimer complètement de votre système informatique.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

From: Nicholas Caton <ncaton at catonenergy.com>
Sent: Monday, October 12, 2015 5:24 PM
To: 'equest-users at lists.onebuilding.org' <equest-users at lists.onebuilding.org>
Cc: 'juan.sanabria at cts-cr.com' <juan.sanabria at cts-cr.com>; 'Eric Fischel J.' <eric.fischel at cts-cr.com>; 'Brian Fountain' <bfountain at greensim.com>
Subject: RE: [Equest-users] Demand Direct Process Load

Y’know, I’ve long thought this is something we as a community could use a illustrated reference/guide on.  The recent ASHRAE energy simulation conference in Atlanta fueled me with some community supporting spirit, so let’s tackle that!

For those who have already figured out this puzzle:  some elements are like an onion, and you may not have uncovered all the layers (you too might find this worth a read)!  I’m going to do conclude with some ‘best practice’ advice for LEED model documentation.  That’s sure to be different from others smarter than myself, and it may prove helpful on the developers side as well for further developing eQUEST’s capacity for aiding with LEED reporting.  I very much encourage discussion!

Let’s start with some extra context based on my understanding of the “problem:”

Based on my personal exposure to GBCI review commentary over the past year or so, the LEED reviewership body seems to have adopted a general policy of “spot checking” various reported inputs by approximating “equivalent full load hours” (also coined “FLE hours”).  Essentially, the idea is by dividing a given enduse’s annual consumption by the corresponding peak demand (i.e. kWh/kW = h), you can get a sense of whether the associated annual operations are nonsensical or else require further clarification.  From a review perspective (or for internal QC & model development), this is a fantastic “back-of-envelope” check to keep handy for evaluation of results.  I choose a word as strong as “fantastic,” because there are precious few QC checks that can be performed so rapidly & directly within the eQUEST user interface, without jumping into custom hourly and SIM reports (the natural progression if this suggests symptoms of a bigger issue).

In a perfect world, this sort of check would never lead to misunderstandings.  There are however a number of pitfalls on both the reviewing and receiving ends that can lead to “false positives” for model input problems, not the least of which is an incomplete/incorrect understanding of the nuances between what the eQUEST interface (“rainbow”) reports, SIM reports, and LEED CSV output reports are actually telling us in terms of peak demands.

So here for consideration are a series of output screenshot excerpts I’ll refer to for a single simulation run.  I have cropped/isolated/highlighted content to focus the discussion on a single end-use (space cooling).  I have also deliberately selected a LEED submission project for illustration which isn’t the simplest case**, so that we can cover additional sides of the issue you won’t encounter under every project:

  *   Monthly Peak Demand by Enduse (rainbow report):

[cid:image010.png at 01D0FF84.373831E0]

  *   The above rainbow report illustrates a situation where the annual peak is not clear, due to automated rounding.  0.47 MW is indicated for space cooling for both May and August.  The ‘rainbow reports’ for consumption/demand reference the same information written to an output file whose name ends with “_EG_MoEU_ED.csv” in the project directory (*).  Following is an excerpt which comes from the corresponding CSV, and shows the monthly maximum values before rounding.  We can see more clearly the highest monthly peak value for space cooling occurs in August:

[cid:image018.png at 01D0FF75.0CB59E30]

  *   Here is the PS-E SIM report for all Electric Meters – I’ve added some annotations/highlighting for clarity:

[cid:image013.png at 01D0FF7D.8C829F70]

  *   The PS-F SIM report for EM1:

[cid:image017.png at 01D0FF7D.8C829F70]

  *   Finally, to complete the picture of probable misunderstandings, let’s also consider the summary excerpt from the current File --> Export File --> LEED Results (CSV)… feature:

[cid:image024.png at 01D0FF6D.BB1ECB20]

So with these visuals handy, let’s summarize the figures in front of us:

  1.  Rainbow reports: maximum demand value for ‘space cooling’ = 472.167 kW, occurring in the month of August.
  2.  PS-E report: annual “MAX KW” is 474.025 kW, in June
  3.  PS-E report: annual “PEAK ENDUSE” = 460.149 kW, in June.
  4.  PS-F for EM1: annual “MAX KW” = 474.025 kW, in June.
  5.  PS-F for EM1: annual “PEAK ENDUSE” = 471.084 kW, in June.
  6.  LEED CSV output: 471.084 kW, (unspecified time).

CLEARLY… the water is muddy so far.  For those keeping score, I have 4 different values to differentiate here.

In order of largest to smallest:

  *   474.025 kW:  PS-E and PS-F (for EM1) agree on this “MAX KW” value for space cooling.  This is the highest draw for ‘space cooling,’ independent of meters & coincident peak draw hours for the entire year:  “Non-coincident enduse peak.”
  *   472.167 kW:  This maximum peak demand from the ‘rainbow report’ is the contribution of ‘space cooling’ at the hour of highest electrical draw in the month of August, for all electric meters.  This is the demand at the “coincident peak” for the year.
  *   471.084 kW:  As confirmed with the developers (thanks!), the LEED CSV output feature by design sums the annual “PEAK ENDUSE” (read “annual coincident-peak”) outputs for all PS-F reports to come up with “Baseline/Proposed Design Demand” outputs.  These sum results can in turn come from a variety of different peak hours during the simulation (those for each meter), and therefore do not cleanly fit the definitions of “MAX KW” or “PEAK ENDUSE.”  In this case, we are seeing the contributions of space cooling during the annual peak coincident hour as seen by meter EM1 in isolation.  That this value differs from the ‘rainbow report’ maximum value is because the loads on non-EM1 meters are shifting the coincident peak hour for the whole building away from what the loads under EM1 alone would suggest.  (An aside: I promise, I’ve proofed this passage a few times and am struggling to convey this more clearly!)
  *   460.149 kW:  This is what ‘space cooling’ contributes to the coincident-peak consumption for the year, for all electric meters.  This is distinct from and lower than the maximum rainbow report value, because the annual building peak occurs in the month of June instead of August.

Suggested “Best Practices” for LEED documentation (TLDR!):

  *   When you have only the default utility meters EM1 and FM1:  The annual “MAX KW” / “MAX MBTU/HR” values found at the bottom of the PS-E reports are the most representative/intuitive quantities in consideration of how they are leveraged in LEED model reviews for “equivalent full load hours.”  They represent the maximum “non-coincident peak” for each enduse, for the whole project.  For preliminary submission, use those for reporting simulation enduse demand, and include at least the PS-E reports in the collection of SIM reports you elect to upload for supporting documentation.  BE AWARE these values do not match the “coincident peaks” visualized with the rainbow reports.
  *   When you have more than one of any type of meter (commonly to distinguish and separately document loads that would otherwise fall under the same enduse category):  Refer instead the “MAX KW” / “MAX MBTU/HR” annual values found at the bottom of the PS-F reports for each meter, and include all PS-F reports in your supporting documentation.  Recognize the peak non-coincident enduses for the master meters (EM1/FM1) may require some addition/subtraction of the other meters’ peaks if you elected to define the additional meters on a different level (i.e. submeters instead of utility).
  *   If you elect to include any of the “rainbow reports” in supporting LEED documentation, be mindful these are all built upon “coincident peaks” of one form or another, and do NOT represent “non-coincident” or “independent” maximum draws for each enduse.  I for one have gravitated away from providing any of these graphical reports, as they seem to be a common source for misunderstanding/confusion when a reviewer is looking for documentation issues.  If I have to explain one more time why there isn’t any exterior lighting demand during the monthly coincident peak hours…. =)
  *   DO recognize this sort of “full load equivalent hours” check/approximation is very easy to perform and can save you time in review/QC of simulated models, directly from the eQUEST user interface.
  *   Also recognize NONE of these peak/demand outputs can be counted on as equivalent to “installed capacity,” which is what a GBCI reviewer is generally looking for to approximate “full load equivalent hours.”

     *   Some common causes for this divergence include:

        *   Any fractional schedules for loads which do not hit 100% (including every ASHRAE-recommended fractional schedule for every occupancy type, excepting parking garages),
        *   All oversizing factors for system heating/cooling capacities (i.e. every correctly autosized 90.1 baseline system, ever),
        *   and the variety of operational inputs concerning systems’ behavior will cause enduse demand figures of all stripes to diverge from “installed capacity.”

     *   Reviewers and diligent modelers interesting in QC’ing their efforts alike are encouraged to “dive deeper” and seek more case-specific inputs/outputs to ensure operating hours are within reason, when such an approximation causes raised eyebrows.

Wishing everyone the best,

~Nick

* An interesting footnote:  As it stands uncorrected, I believe “_EG_MoEU_ED.csv” stands for “Every Good Modeler Educates the Uniformed Each Day,” as proposed by Mr. Bill Bishop earlier this year over these mailing lists.

** In hindsight, there are a few other possible pitfalls in demand reporting I didn’t hit with this example, which would fall under the category of “best practices for metering structure…” (a writeup for another day!)  For now I’ll just say to be extra mindful with your meters when you are simulating any on-site power generation, cogeneration, tri-generation, and specific cases for district heating/cooling networks.

NICK CATON, P.E.
Owner

Caton Energy Consulting
  306 N Ferrel
  Olathe, KS  66061
  office:  785.410.3317
www.catonenergy.com

From: Equest-users [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Eric Fischel J.
Sent: Friday, October 02, 2015 3:43 PM
To: Brian Fountain; equest-users at lists.onebuilding.org<mailto:equest-users at lists.onebuilding.org>
Subject: Re: [Equest-users] Demand Direct Process Load

Hello Brian, that right there is a shift in the moment of the peak demand.
Does anyone know how to resolve this in the model or in any case how to deal with it in the LEED submittal for the reviewrs no to coment on it?

I have done lots o models and never came acorss with this issiue previsuly.

Best regards.

  Ing. Eric Fischel J.
   Tel.: (506)  2222-7529
  Fax: (506)  2256-5608
  From USA: 1-305-433-3668
  Calle 30, Avenida 0 y 2. San José, Costa Rica

[Logo CTS firma]                 [Description: LEEDAP_BDCbw]           [cid:image016.jpg at 01D4D347.608BCB20]
Este correo puede contener información protegida por el secreto profesional. Si usted no es la persona a quien va dirigido, por favor tome en cuenta que su divulgación, distribución o reproducción es estrictamente prohibida. Cualquier persona que reciba este mensaje por error debe notificarlo inmediatamente al remitente vía telefónica o correo electrónico y borrarlo permanentemente de su computador. Los comentarios plasmados en este correo son del remitente solamente y no reflejan necesariamente la posición de CTS S.A.
Por favor considere su responsabilidad con el medio ambiente antes de imprimir este correo electrónico
----------------------------------------------------------------------------------------------------------------
This mail may contain information that is legally privileged, confidential or exempt from disclosure.  If you are not the intended recipient, please note that any dissemination, distribution or copying of this message is strictly prohibited.  Anyone who receives this message in error should notify the sender immediately by telephone or by e-mail and delete it permanently from their computer.  The opinions above are those of the author and do not necessarily reflect the position of CTS S.A.
Please consider your environmental responsibility before printing this e-mail

From: Brian Fountain [mailto:bfountain at greensim.com]
Sent: Thursday, October 01, 2015 1:43 PM
To: equest-users at lists.onebuilding.org<mailto:equest-users at lists.onebuilding.org>; Eric Fischel J. <eric.fischel at cts-cr.com<mailto:eric.fischel at cts-cr.com>>
Subject: Re: [Equest-users] Demand Direct Process Load

I would look at your PS-E report to see when the peak loads are occurring in your proposed and baseline models.  I suspect that the slight shift in when the peak demand is being set changes the breakdown of that peak demand.
On 01/10/2015 2:18 PM, Eric Fischel J. wrote:
Hello David, thanks for the tip on the process loads.

In the following table the results show that the KWh for the receptacle equipment is the same but we get -15.4029 in demand saving. (We triple check schedules and w/sf they are exactly the same)
Additionally we use the “Exterior Usage” and “Task Lighting”  categories in the Electric Meter Direct loads ( for water pump, elevator, exterior lighting), using the same Schedule and Load (KW). As you can see the show saving in Demand.

What would we change In the *.SIM file to get the same results in the process load?

Thanks again for your help!

[cid:image017.png at 01D4D347.608BCB20]

[cid:image018.png at 01D4D347.608BCB20]

  Ing. Eric Fischel J.
   Tel.: (506)  2222-7529
  Fax: (506)  2256-5608
  From USA: 1-305-433-3668
  Calle 30, Avenida 0 y 2. San José, Costa Rica

[Logo                  CTS firma]                 [Description: LEEDAP_BDCbw]           [cid:image021.jpg at 01D4D347.608BCB20]
Este correo puede contener información protegida por el secreto profesional. Si usted no es la persona a quien va dirigido, por favor tome en cuenta que su divulgación, distribución o reproducción es estrictamente prohibida. Cualquier persona que reciba este mensaje por error debe notificarlo inmediatamente al remitente vía telefónica o correo electrónico y borrarlo permanentemente de su computador. Los comentarios plasmados en este correo son del remitente solamente y no reflejan necesariamente la posición de CTS S.A.
Por favor considere su responsabilidad con el medio ambiente antes de imprimir este correo electrónico
----------------------------------------------------------------------------------------------------------------
This mail may contain information that is legally privileged, confidential or exempt from disclosure.  If you are not the intended recipient, please note that any dissemination, distribution or copying of this message is strictly prohibited.  Anyone who receives this message in error should notify the sender immediately by telephone or by e-mail and delete it permanently from their computer.  The opinions above are those of the author and do not necessarily reflect the position of CTS S.A.
Please consider your environmental responsibility before printing this e-mail

From: David Eldridge [mailto:DEldridge at grummanbutkus.com]
Sent: Tuesday, September 22, 2015 8:51 AM
To: Juan Carlos Sanabria F. <juan.sanabria at cts-cr.com><mailto:juan.sanabria at cts-cr.com>; equest-users at lists.onebuilding.org<mailto:equest-users at lists.onebuilding.org>
Subject: Re: [Equest-users] Demand Direct Process Load

Double check the timing of the peaks – the graphical presentation in eQUEST is the coincident peak – the contribution of each component at the time that the building hits its total highest demand.

It’s likely that the proposed building has a peak later in the day due to one or more efficiency measures that are included. If the process loads are lower at this time, the graphical presentation will show that the peak component is less than the baseline case. (Or if the process ramps up later in the day, it could be more?)

You’ll need to go into the *.SIM file to get the reported peaks for the process loads (and show the annual totals to also be the same) to demonstrate that the schedules are consistent, or otherwise explain to the reviewer what is happening.

David

David S. Eldridge, Jr., P.E., LEED AP BD+C, BEMP, BEAP, HBDP
Grumman/Butkus Associates

From: Equest-users [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Juan Carlos Sanabria F.
Sent: Monday, September 21, 2015 6:10 PM
To: equest-users at lists.onebuilding.org<mailto:equest-users at lists.onebuilding.org>
Subject: [Equest-users] Demand Direct Process Load

Hi,
I’m modeling a building for LEED, but when I go to equest LEED report I notice that my direct process load for demand is not equal, anyone know why this happen?

I review the rate and the schedules and are the same also the energy load is the same for the proposed and the baseline.

Thanks,
  Ing. Juan Carlos Sanabria F.
   Tel.: (506) 2256-7020
  Fax: (506) 2256-5608
  From USA: 1-305-433-3668
  Calle 30, Avenida 0 y 2. San José, Costa Rica

[Logo                CTS firma]
Este correo puede contener información protegida por el secreto profesional. Si usted no es la persona a quien va dirigido, por favor tome en cuenta que su divulgación, distribución o reproducción es estrictamente prohibida. Cualquier persona que reciba este mensaje por error debe notificarlo inmediatamente al remitente vía telefónica o correo electrónico y borrarlo permanentemente de su computador. Los comentarios plasmados en este correo son del remitente solamente y no reflejan necesariamente la posición de CTS S.A.
Por favor considere su responsabilidad con el medio ambiente antes de imprimir este correo electrónico
----------------------------------------------------------------------------------------------------------------
This mail may contain information that is legally privileged, confidential or exempt from disclosure.  If you are not the intended recipient, please note that any dissemination, distribution or copying of this message is strictly prohibited.  Anyone who receives this message in error should notify the sender immediately by telephone or by e-mail and delete it permanently from their computer.  The opinions above are those of the author and do not necessarily reflect the position of CTS S.A.
Please consider your environmental responsibility before printing this e-mail

_______________________________________________

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<mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 255 bytes
Desc: image001.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0042.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8477 bytes
Desc: image002.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0043.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 7123 bytes
Desc: oledata.mso
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 26283 bytes
Desc: image003.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0044.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 59502 bytes
Desc: image004.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0045.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 75485 bytes
Desc: image005.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0046.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 21338 bytes
Desc: image006.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0047.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 55634 bytes
Desc: image007.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0048.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 5690 bytes
Desc: image008.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0024.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 102689 bytes
Desc: image009.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0049.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 6501 bytes
Desc: image010.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0050.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.png
Type: image/png
Size: 454513 bytes
Desc: image011.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0051.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.png
Type: image/png
Size: 378941 bytes
Desc: image012.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0052.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image013.png
Type: image/png
Size: 16952 bytes
Desc: image013.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0053.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image014.jpg
Type: image/jpeg
Size: 5450 bytes
Desc: image014.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0025.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image015.jpg
Type: image/jpeg
Size: 3228 bytes
Desc: image015.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0026.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image016.jpg
Type: image/jpeg
Size: 2943 bytes
Desc: image016.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0027.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image017.png
Type: image/png
Size: 29472 bytes
Desc: image017.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0054.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image018.png
Type: image/png
Size: 39439 bytes
Desc: image018.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0055.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image019.jpg
Type: image/jpeg
Size: 5920 bytes
Desc: image019.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0028.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image020.jpg
Type: image/jpeg
Size: 3423 bytes
Desc: image020.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0029.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image021.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: image021.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0030.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image022.jpg
Type: image/jpeg
Size: 5449 bytes
Desc: image022.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190305/acdfd8fe/attachment-0031.jpg>