[Equest-users] DOAS Dummy Warnings - no problem?

R B slv3sat at gmail.com
Tue Mar 23 04:19:50 PDT 2010


Question - 1: I believe that to be the case. What I had done ususally
is to use the DCV features and proportion the OA and related ERV, fans
etc. if any to the individual systems.

Question #1 - I have used this also but had run into some issue, but
cannot recollect whatthat was. It is a reasonable way to model. The
CO2 usually has a lag of 20-30 minutes, so you could shift your
schedule accordingly. But the DCV model in eQuest anyway does not
consider the lag - it is strictly number of people times the OA cfm
required.

-Rohini
On 3/23/10, Nick Caton <ncaton at smithboucher.com> wrote:
> I am revisiting this model and never received a response, and I see
> another has run into the same warnings.  Reposting/rephrasing for any
> suggestions/input:
>
>
>
> In hindsight perhaps I can phrase a simpler set of questions:
>
>
>
> 1.       True or False: Is it simply impossible in eQuest to
> simultaneously use OA-FROM-SYSTEM and either of the DCV ventilation
> control methods with the same system.  This appears to be the case.
>
> 2.       Based on #1, I seem to be stuck being unable to modeling the
> savings from DCV at the zonal level (instead forced to use fraction of
> design or the like for my min-OA method)...
>
>
>
> But I've got a crazy idea:  For an alternative way to force DCV
> behavior, might I define a set of MIN-AIR-SCHEDULE's, using the zonal
> occupancy schedules as a template, and multiply each fractional
> occupancy rate by the designed OA ratio?  This would be tied to an
> assumption that the C02 levels rise and fall instantaneously with the
> occupancy, which I know is not true but may be an acceptable
> approximation given #1.
>
>
>
> Example:  A classroom has a daily schedule that looks like this (this is
> for evening classes, if this looks odd):
>
>
>
> "General Classroom Occup Mon-Thu" = DAY-SCHEDULE-PD
>
>    TYPE             = FRACTION
>
>    VALUES           = ( 0, &D, &D, &D, &D, &D, 0.2, &D, &D, &D, &D, &D,
> &D,
>
>          &D, &D, &D, 0.6, 1, &D, &D, &D, &D, 0.5, 0 )
>
>    ..
>
>
>
> With the design OA flow being 60% of the design Supply Air flow for that
> terminal unit, I create a new MIN-AIR-SCHEDULE multiplying through:
>
>
>
> "General Classroom MinAir Mon-Thu" = DAY-SCHEDULE-PD
>
>    TYPE             = FRACTION
>
>    VALUES           = ( 0, &D, &D, &D, &D, &D, 0.12, &D, &D, &D, &D, &D,
> &D,
>
>          &D, &D, &D, 0.36, 0.60, &D, &D, &D, &D, 0.30, 0 )
>
>    ..
>
>
>
> For this approach I would tightly control the OA present at each zone
> specifying MIN-OUTSIDE-AIR and clearing out the zonal-level OA inputs.
>
>
>
> For reference - The system I am trying to model is:
>
> *         Dedicated outside air unit - HW/CHW coils, enthalpy recovery
> wheel, variable supply which effectively sums the terminal fan coil's
> call for OA over time.  Conditioned OA is supplied to VAV's which
> modulate based on the terminal fan-coil's DCV sensor.
>
> *         Terminal units of widely varying size:  4-pipe HW/CHW coils
> which handle essentially all the internal/envelope loads, constant
> volume, local thermostat controlled, conditioned OA from dedicated OA
> units ties into supply ductwork (not seen by the terminal fan coil
> units).  OA is modulated down to zero based on a CO2 sensor in return
> path.
>
> For reference - I'm trying to model the above using:
>
> *         Single Zone Reheat (SZRH) for the DOAS, tied to a dummy zone
>
> *         4-pipe Fan Coil (FC) for the terminal units, system per zone,
> OA-FROM-SYSTEM
>
>
>
> ~Nick
>
>
>
>
>
>
>
> 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 Jacob
> Goodman
> Sent: Friday, December 18, 2009 3:24 PM
> To: equest-users at lists.onebuilding.org
> Subject: Re: [Equest-users] DOAS Dummy Warnings - no problem?
>
>
>
> I saw your question on the warnings from your DOAS model and didn't see
> any replies. I have some of those same warnings.
>
>
> **WARNING***************************************************************
> *******
>              EL1 Sys1 (PVVT) (G.SW1)          has a MIN-AIR-SCH,
> OA-CONTROL
>              other than FIXED and/or a MIN-OA-METHOD other than
> FRACTION-OF-DESIGN
>              along with having a specified OA-FROM-SYSTEM. This may
> cause incorrect
>              OA load/flow calculation for its OA-FROM-SYSTEM.
>
> Shows up for each zone the DOAS is supplying and so does:
>
>
>
> **WARNING***************************************************************
> *******
>              SYSTEM EL1 Sys1 (PVVT) (T.C12)          has zero outside
> air for design calculations
>
> the second one seems normal since I put 0 cfm OA in the DD wiz before I
> went to detailed edit mode, but I'm not sure about the first one.
>
> Hope your model turned out well, for both of our sakes.
>
> Thanks,
>
> --
>
> Jacob Goodman , LEED AP, Green Building Specialist
> v:509.747.2179  f:509.747.2186  i:www.lseng.com <http://www.lseng.com>
> L&S  Engineering Associates, Inc.
> 'High Performance Design'
>
>
>
>
>
> From: equest-users-bounces at lists.onebuilding.org
> [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Nick
> Caton
> Sent: Friday, September 25, 2009 2:58 PM
> To: equest-users at lists.onebuilding.org
> Subject: [Equest-users] DOAS Dummy Warnings - no problem?
>
>
>
> Hi everyone,
>
>
>
> I've got what I believe to be a working preliminary model of a DOAS
> system.  I'm following the DOAS concept (prescribed by previous archived
> discussions) of creating a "dummy zone/shell" to be served by the DOAS
> equipment.  All terminal units are tied to the DOAS via OA-FROM-SYSTEM.
> My DOAS is based on the system type SZRH ("Single Zone Air Handler with
> HW reheat").
>
>
>
> This DOAS is assigned to a 1ft-cube "dummy shell" with a single zone,
> adiabatic ceiling/floor constructions, wall constructions of U=.0001,
> and zeroed-out internal loads.  Conceptually, I believe the airflow for
> the DOAS should be calculated as the hourly sum of all the terminal
> unit's calculated OA needs.
>
>
>
> I've got three basic questions, presented in order of (perceived)
> difficulty:
>
>
>
> QUESTION 1)
>
> As I've set my "dummy" zone's walls to U=0.0001, and of physically tiny
> dimensions, I don't think there's much to worry about regarding heat
> gains/losses.  In the interest of doing the intuitively "right" thing
> however, is there a way to set their "surface type" as adiabatic in the
> same way as roof and floor surfaces?  Is perhaps the cleanest way to
> deal with all three to create "adiabatic" constructions, and if so how
> do you get around the error (see attached image) when you input U=0?
>
>
>
> QUESTION 2)
>
> Every system (DOAS and terminal units) currently has the MIN-OA-METHOD
> set as FRACTION-OF-DESIGN, per the warning below.  In reality, the
> hourly OA supplied by the DOAS will be calculated by summing what is
> being called for by all of the terminal units, which will be based on
> local DCV sensors in the return air path of each unit.  Unfortunately,
> setting any of the terminal units' MIN-OA-METHOD to the intuitive
> DCV-RETURN-SENSOR results in the following warning (typical for each
> system):
>
>
>
> **WARNING***************************************************************
> *******
>
>              EL1 Sys1 (FC) (G.N1)             has a MIN-AIR-SCH,
> OA-CONTROL
>
>              other than FIXED and/or a MIN-OA-METHOD other than
> FRACTION-OF-DESIGN
>
>              along with having a specified OA-FROM-SYSTEM. This may
> cause incorrect
>
>              OA load/flow calculation for its OA-FROM-SYSTEM.
>
>
>
> I've gathered that one approach to this problem is to manually define
> the design airflow of the DOAS, based on summing the critical case of OA
> required by digging through the reports (not sure where to begin there),
> but is there any way of tricking eQuest into correctly summing the
> hourly OA CFM required by all terminal units tied to the DOAS, and then
> sizing the DOAS system based on that critical sum?
>
>
>
> QUESTION 3)
>
> The following are the remaining 3 warnings, all referring to this "dummy
> zone:"
>
>
>
> **WARNING***************************************************************
> *******
>
>              Zone: EL2 Zn (G.1)                     has a design cooling
>
>              temperature differential of only  1.0F.  This
>
>              may result in an extremely large design airflow.
>
>
>
>
> **WARNING***************************************************************
> *******
>
>              Zone: EL2 Zn (G.1)                     has a design heating
>
>              temperature differential of only  -1.0F.  This
>
>              may result in an extremely large design airflow.
>
>
>
>
> **WARNING***************************************************************
> *******
>
>              ZONE EL2 Zn (G.1)
>
>              might have insufficient heating capability.
>
>              Check that the SYSTEM or ZONE HEATING-CAPACITY plus this
>
>              ZONEs BASEBOARD-RATING is adequate to maintain the ZONE
>
>              specified DESIGN-HEAT-T for the calculated peak ZONE load
>
>              (see LS-A or LS-B for the ZONE peak load.)
>
>
>
> Which (if any) of these I should be addressing/evaluating, considering
> the modeling function of this "dummy zone?"  In other words, can I
> ignore these and sleep well at night? =)
>
>
>
>
>
>
>
> 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
>
>
>
>



More information about the Equest-users mailing list