[Equest-users] FW: DOE 2.3 - VRF custom curves

Nicholas Caton Nicholas.Caton at se.com
Mon Jul 15 20:49:52 PDT 2019


**CAUTION**********************************************************************
     In User:  Patrick the dependent value is exceeding the limits of
VRF knowledge.


**ERROR************************************************************************

Information dump detected.  Last occurrence on 7 / 15 / 22
Simulation Aborted.


My understand of the "how" to-date is perhaps best informed by sharing the understanding that the doe 2.3 VRF performance curves in their present state may be fairly considered an "evolution" upon the energyplus library defaults, and with that comes a blend of both benefits and drawbacks in their application.

The following link will lead you to a zip file of reports and documentation concerning VRF systems, which provide extra insight into the research performed by Hirsch's team in evaluating and making the decision to go in this "new" direction for component-based modeling of VRF systems (triggering performance curves with different inputs):
http://deeresources.com/index.php/deer-versions/deer2019-and-june-2017-updates#VRF<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdeeresources.com%2Findex.php%2Fdeer-versions%2Fdeer2019-and-june-2017-updates%23VRF&data=02%7C01%7CNicholas.Caton%40schneider-electric.com%7Ce24cf74de1a74ca2405908d648db8e2c%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636776505156944555&sdata=qbJUP6UGGYNGj1xgDlHmCFtopfmg3A7jRcnbGazgmcM%3D&reserved=0>
(Username:  DEER, Password: 2008)

For Patrick (and anyone else with similar questions now or in the future), I think you'll specifically find a lot of answers in the document "VRF_Performance Asssessment_Feb2017_v1.docx"

I too am still on the learning path, but here are some key takeaways I can share with a certain degree of confidence:

  *   After working with engineering staff of multiple VRF product vendors and studying their respective published literature/manuals, it was found (by the JJH team) that everyone (or essentially most manufacturers) is using the same mechanical compressor for their VRF systems
  *   ... whereas Energyplus curves are based on a large, Danfoss compressor on the order of 12-13 tons - and typically larger VRF systems instead make use of a series of smaller compressors (more commonly 6-7 tons).
  *   How exactly these compressors are controlled varies more so between manufacturers, but controlling the compressors as a function of SST was found to be the most common mechanism
     *   Ergo, the new library default curves supplied with the current eQuest/doe2.3 package should be compatible and aligning with performance of multiple manufacturers.
     *   Further, modifying the library performance curves infers you actually have different compressors... better to check that first!
  *   So why are we seeing SST?  Manufacturers rate VRF systems on AHRI conditions (indoor/outdoor DB/WB) and testing standards which in part stipulate arbitrarily longer refrigerant loops  for systems of increasing capacity.  Clearly from the direction the eQuest/doe2.3 development has taken, we are leveraging a platform which instead goes one level deeper to give us simulators control over the construction, length, and other pertinent performance variables concerning the refrigerant circuit design and routing, so that we can work out building and system specific performance to a greater degree of accuracy.  The big con here is that it remains in fact trickier to compare library vs. manufacturer-published system performance (hint - you probably want to instead compare library curves to compressor performance... hopefully achievable for you with strong vendor support), however the Pro to this direction is that we can step that much closer to evaluating actual VRF system performance (or viability against alternative system options) for a given building, considering how the system would be designed.

[cid:image004.png at 01D538C6.B355EA90]

  *   In my experience, "considering how the system would be designed" in the previous bullet may be characterized as the energy analyst coordinating with others and taking an ownership role in helping to draft the performance specification for the system under consideration, in coordination with other MEP system designers and whatever vendors/manufacturers are playing a role in recommending some of the detailed inputs we'll be seeking when using leveraging doe2.3 for such purposes.
  *   This decision for the development path of doe2 to "go deeper" than the immediate existing industry framework (or status quo) I think has some precedent established over the last decade (and perhaps beyond - that's getting beyond my years).  You can look for example to our present options in the eQuest interface for defining GLHX well fields and solar PV arrays.  In each case, the optional/required model inputs in a fashion go above and beyond some of the more commonly prescribed design tools (free and for-cost) in the industry "purpose-built" for aiding in designing such systems.  The depth of knowledge required to fully leverage and make use of these inputs borders on academic (great for research, potentially tricky for practicing engineers who are not specializing in such systems), but allows for some very fine control in studying, modeling, and calibrating such systems.



At the present (still lacking a ton of project experience under doe 2.3, where I only recently made the full jump for 'real' projects), I feel this implementation of VRF system definition and simulation represents a better balance between "control" and "practical application," as the most esoteric of inputs seem readily answerable between the reference manual articles provided, a vendor/installer phone call, and/or a coordination meeting with the system designer.  On this just-made-up scale: I'd position the definition and mastery of VRF systems in doe2 as approaching  custom chillers in relative difficulty/complexity, but given cooperative/capable specification/design support from a VRF manufacturer I expect VRF is most often much easier due to the relatively thorough / clear documentation put in front of us via the reference manual... that said, a doe2 "engineering manual" update to include some of the details referenced in the linked documentation/reporting would certainly help!

  *   The manufacturer-endorsed approaches available to us for VRF simulation prior to doe2.3 today, in hindsight, feel relatively circumspect.  I would hesitate to recommend their application any longer, considering the relative stability and functionality of the most current doe2.3 platform and the improvements with specific regard to VRF systems AND DOAS ventilation systems, which are most commonly featured together, in my experience.

I hope this helps.  I also hope that as others build their understanding and learn to apply this knowledge, you'll share your findings in kind!

~Nick

[cid:image005.png at 01D515A3.47EDD880]
Nick Caton, P.E., BEMP
  Senior Energy Engineer
  Regional Energy Engineering Manager
  Energy and Sustainability Services
  Energy Performance Contracting
D
M
F
E
913 . 564 . 6361
785 . 410 . 3317
913 . 564 . 6380
nicholas.caton at se.com<mailto:nicholas.caton at se.com>
15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219
United States
[cid:image006.png at 01D515A3.47EDD880]


From: Equest-users <equest-users-bounces at lists.onebuilding.org> On Behalf Of Lapierre, Patrick via Equest-users
Sent: Friday, July 12, 2019 8:24 AM
To: equest-users at lists.onebuilding.org
Subject: [Equest-users] DOE 2.3 - VRF custom curves


[External email: Use caution with links and attachments]

________________________________


Good day everyone,

I've been looking at the new VRF capacities of DOE 2.3 and tried coming up with custom VRF curves to match the specifications of my VRF units but I'm having some problems.
DOE 2.3 curves are function of saturated suction temp (SST) and saturated discharge temp (SDT) - However the specifications I have are functions of Outdoor DB and Indoor WB, and I'm not exactly sure how to translate these DB / WB temps into SST / SDT. Seems to me I'm missing something here.

I've looked at the guide made by Florida Solar Energy Center - it seems fine for EnergyPlus since its curves uses Outdoor DB and Indoor WB. But it doesn't gives any insight on DOE 2.3 (or at least I didn't catch any).
http://publications.energyresearch.ucf.edu/wp-content/uploads/2018/06/FSEC-CR-1910-12.pdf<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublications.energyresearch.ucf.edu%2Fwp-content%2Fuploads%2F2018%2F06%2FFSEC-CR-1910-12.pdf&data=02%7C01%7CNicholas.Caton%40se.com%7Cadbc97f1bbc446fc034208d706cc2ebb%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C1%7C636985346336324664&sdata=UTfw4RUuIJt0gNB680MImmNEaHb6NhriRylhZrJfbEU%3D&reserved=0>

I've also looked at Maddox's presentation on VRF - There's a slide that says that E+ and DOE 2.3 curves uses the same parameters and are interchangeable but I don't really understand the "how" of it.

So general question goes as follows:

  *   Did anyone have success in creating custom VRF curves for DOE 2.3? If so, would you be so kind as to share the method?
  *   If not, does everyone simply uses the library curves, whatever the VRF model may be?

Thanks in advance for the insights,


  [Bouthillette Parizeau] <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bpa.ca%2F&data=02%7C01%7CNicholas.Caton%40se.com%7Cadbc97f1bbc446fc034208d706cc2ebb%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C1%7C636985346336334658&sdata=Xgde5C00CKSO2JB%2B76AYU%2FDbc1L8boVrzbmcl2pbK7k%3D&reserved=0>
Patrick Lapierre_ing. BEMP
Développement durable et Efficacité énergétique
plapierre at bpa.ca<mailto:plapierre at bpa.ca>   |  www.bpa.ca<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bpa.ca&data=02%7C01%7CNicholas.Caton%40se.com%7Cadbc97f1bbc446fc034208d706cc2ebb%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C1%7C636985346336334658&sdata=rWtUXjVpm%2F%2FNznb8EH7x%2BpkXPSPtDWwUitA7Pl5bOt8%3D&reserved=0>  |  t: 5143833747x2807



Avertissement / Disclaimer

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.

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190716/b0305d92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5690 bytes
Desc: image001.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190716/b0305d92/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 255 bytes
Desc: image002.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190716/b0305d92/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 8477 bytes
Desc: image003.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190716/b0305d92/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 12243 bytes
Desc: image004.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190716/b0305d92/attachment-0002.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20190716/b0305d92/attachment.txt>


More information about the Equest-users mailing list