why vrf system by autosizing in equest generate many unmet hours

asked 2016-01-12 17:17:17 -0600

Can someone help me?, I modeled a PVVT system with variable speed compressor to represent a VRF system in eQuest, but the BEPU report show to many unmet hours (2400 app between cooling and heating). This is weird, to being an autosizing system, should not comply with the requirements "automatically" or to least not generate so many unmet hours? I think it's because some equipment supply thermal energy two to three zones and the flow of does not reach. To analize this condition I simulated a chiller with fancoils units in autosizing, and the unmet hours are 800 app.

edit retag flag offensive close merge delete

Comments

Do you have zonal exhaust? Or is one of your zone adjacent to a semi-heated or unconditioned space?

Julien Marrec ( 2016-01-13 00:51:31 -0600 )edit

Julien, the model do not have a exhaust system, neither zones adjacent to semi-heated or unconditioned space.

carlos.zamorano ( 2016-01-13 08:39:12 -0600 )edit

There are a couple things which come to mind. The first is related to Julien's point above - while the BEPU report gives the coincident unmet hours for the building [which is what LEED/Apdx G care about], use the SS-R report to check which zone[s] have the unmet hours. This will narrow it down. Secondly, you mentioned that some equipment serves multiple zones, for PVVT a control zone must be specified. Two parts 1-is this in the "worst" zone? 2-does it match plans? PVVT will control to the needs of the Control Zone, other zones get what they get.

dradair ( 2016-01-13 08:57:43 -0600 )edit

The final thing, with auto-sizing, from the DOE2 documentation I've seen, the calculations use the Design Day data, which does not necessarily align / can be different from the weather file. Check that the Design Day inputs make sense [schedules/setpoints/etc]

dradair ( 2016-01-13 08:59:52 -0600 )edit

@rraustad, how does one move a comment to become an answer?

Chris Jones ( 2016-01-13 09:16:28 -0600 )edit

see more comments

2 Answers

Sort by » oldest newest most voted

answered 2016-01-14 22:54:47 -0600

Nick Caton
516 ●2 ●4

If you take a hard look at illustrated DOE-2 help entry for PVVT, you'll note that PVVT will not respond well to simultaneous calls for heating/cooling when occurring between the control and slave zones. It is only listening to the assigned 'control zone' to determine (a) heating vs. cooling operation and (b) the amount of conditioned supply air volume available.

One system per zone is an option, but may result in equipment capacities well under what's actually available for custom curves (if I"m correctly guessing which manufacturer you're using)... Another means to avoid this issue is to regroup your PVVT system zones so that you have one system per set of similar load conditions (i.e. skin exposure / occupant scheduling). This should minimize simultaneous calls for heating/cooling within the same system.

Another note: For this exact sort of troubleshooting, you might find it much easier to highlight the top of the component tree under the airside HVAC tab, then to click the 'summary' tab immediately after a simulation. This display will assist you with pinpointing exactly which zones are having substantial unmet heating/cooling hour troubles in relation to their parent systems and by zone group.

edit flag offensive delete link

Comments

Nick, by & large I agree. One thing maybe you can shed some light on/confirm is my second comment above, on if eQuest, when autosizing, it uses design day data, which can be different from the weather file. This can results in issues especially since the 'sizing' is done separately/before the actual 'simulation'. Can you comment/confirm on this?

dradair ( 2016-01-15 08:40:40 -0600 )edit

Confirmed! Sorta... =)

You can easily "trip up" auto-sizing by eQUEST if you do not pay mind to your DESIGN-DAY inputs. To ensure overlap between the design day calculations and with the building's peak in simulation, I'd advise reading up on the optional NUMBER-OF-DAYS input for both cooling and heating design days. I believe it defaults to 1 when you (or the wizards) don't say otherwise.

Also, it's often appropriate when you are trying to match external load calcs/sizing to your model's auto-sizing to specify more stringent design day conditions (i.e. 99.6% for heating).

Nick Caton ( 2016-01-18 16:21:34 -0600 )edit

... continuation comment for exceeding character length...

... I also want to mention DESIGN-DAY inputs are by-and-large most easily editable directly in the INP. In wizard-borne models, they'll be located near the top of the file in the section following Global Parameters. EDIT: you can adjust CDD and HDD NUMBER-OF-DAYS within the interface by double clicking your CDD/HDD in the component tree for the Project & Site tab.

Nick Caton ( 2016-01-18 16:24:54 -0600 )edit

add a comment

answered 2016-01-13 10:11:33 -0600

Chris Jones
1109 ●1 ●6

The EnergyTrust of Oregon presentation by Mark Denyer and Dana Troy states that you must use 1 PVVT system per zone. VRV-VRF Presentation. eQuest doesn't do a good job of automatically sizing the capacities when you have more than one zone on the PVVT system especially in a heated dominated climate.

edit flag offensive delete link

Comments

Seen & reviewed the EnergyTrust of Oregon presentation, It lays out both the Water Source HP and Air Cooled HP approaches, great. It does say 1 system/zone for both, but doesn't give a 'why'; it may have been verbally stated at presentation, but not noted on slides. The issue with this is that 1 system/zone may not reflect the design. One would need to make sure that the 'control' zone is the zone where the t-stat is indicated on plans [or adjust the design, as needed.] In eQuest there is not a different between a zone & space, as there is in EnergyPlus. Combining rooms must be done carefully.

dradair ( 2016-01-15 08:52:28 -0600 )edit

Comment above isn't abrasive, but a note that zoning & sensibly combining multiple rooms into zone must be done carefully, especially with sensitive zone equipment types such as VRF. Chris; Can you comment on/have any experience with the adjusting the Design Day data to address these issues?

dradair ( 2016-01-15 08:54:29 -0600 )edit

@dradair, I have not experimented with adjusting the design day data in eQuest. Note that eQuest does not do a design day calculation for sizing unless specifically instructed to do so. The design day data has to be entered into the eQuest model when specifying a design day calculation. Note that eQuest (doe2.2) has significantly less fields for the design day data than did doe2.1e. I did ask why at one point but I didn't receive an answer. I haven't a feel for how the less design day data fields in doe2.2 affects the sizing calculation.

Chris Jones ( 2016-01-15 09:41:29 -0600 )edit

Hum, I haven't had a chance to play with this either, but good info. I didn't realize the 'downgrade' DOE2.1 to DOE 2.2. With DOE running LOADS simulation, then a SYSTEM simulation, I'd also be curios to know if adjusting the T-sat scheduels are used in both the LOADS and SYSTEM simulations OR if the setpoints in the 'Zones' input would change the sizing/unmet hours. It is known that the Thermostat schedules are used in the SYSTEM simulation, but I don't know if the T-Stat schedules are used in both...hum...

dradair ( 2016-01-15 10:24:16 -0600 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

why vrf system by autosizing in equest generate many unmet hours

Comments

2 Answers

Comments

Comments

Your Answer

Training Workshops

Careers

Question Tools

Stats

why vrf system by autosizing in equest generate many unmet hours edit

Comments

2 Answers

Comments

Comments

Your Answer

Training Workshops

Careers

Question Tools

Stats

why vrf system by autosizing in equest generate many unmet hours