search

NREL / EnergyPlus

EnergyPlus™ is a whole building energy simulation program that engineers, architects, and researchers use to model both energy consumption and water use in buildings.
https://energyplus.net
Other
1.12k stars 389 forks source link

DCV Flag for terminal unit OA control can be wrong for certain combinations #5489

Closed mjwitte closed 8 years ago

mjwitte commented 8 years ago

While addressing #5476 , uncovered a deeper problem with AirLoopControlInfo( OutAirNum ).AirLoopDCVFlag which is used when a terminal unit is controlling outdoor air flow to a zone. When this flag is true, the required OA is calculated using the current number of occupants (DCV). When this flag is false, the OA is calculated using the maximum number of occupants (not DCV).

  1. This flag is set while processing input for Controller:MechanicalVentilation objects.
  2. Currently, the loop for setting this is inside the zone loop, but it should only be checked once for each Controller:MechanicalVentilation object.
  3. The compound if for this block should be split. As it stands now, if VentilationMechanical(1) sets this flag to true for Airloop(1), when VentilationMechanical(2) is processed, the name match will fail for Airloop(1) and it's DCVFlag will be set to false. In other words, the only airloop that can have this flag remain True is the last airloop, all others will get reset to false.
  4. This block assumes that the order of OAController is parallel to the order of airloops (AirLoopControlInfo). If the order of the OA controllers in the idf is different from the order of the airloops, then the flags will not be set correctly.
  5. AirLoopDCVFlag is initialized to True. This means that the flag will be true for any airloop that does not have a matching Controller:MechanicalVentilation object. Is this what we want? @rraustad ?
  6. The I/O Ref description for the terminal units that have an input for DesignSpecification:OutdoorAir needs to be expanded to explain the link to the DCV input in Controller:MechanicalVentilation (if present).

A pair of defect files have been added which are identical except for the order of the OA controllers. The results in the Outdoor Air Summary table are different - they should be the same.

rraustad commented 8 years ago

Why not make it AirLoopControlInfo( OutAirNum ).AirLoopDCVFlag(MechVentNum)

5) It depends on what is done when no MechVent object exists. I guess you wanted me to look.

On 2/17/2016 12:22 AM, Michael J. Witte wrote:

While addressing #5476 https://github.com/NREL/EnergyPlus/issues/5476 , uncovered a deeper problem with AirLoopControlInfo( OutAirNum ).AirLoopDCVFlag which is used when a terminal unit is controlling outdoor air flow to a zone. When this flag is true, the required OA is calculated using the current number of occupants (DCV). When this flag is false, the OA is calculated using the maximum number of occupants (not DCV).

  1. This flag is set while processing input for Controller:MechanicalVentilation objects.
  2. Currently, the loop for setting this https://github.com/NREL/EnergyPlus/blob/c9755cea9f63a0b515ea12331e3b7f0b91ed2796/src/EnergyPlus/MixedAir.cc#L1673-L1679 is inside the zone loop, but it should only be checked once for each Controller:MechanicalVentilation object.
  3. The compound if https://github.com/NREL/EnergyPlus/blob/c9755cea9f63a0b515ea12331e3b7f0b91ed2796/src/EnergyPlus/MixedAir.cc#L1674 for this block should be split. As it stands now, if VentilationMechanical(1) sets this flag to true for Airloop(1), when VentilationMechanical(2) is processed, the name match will fail for Airloop(1) and it's DCVFlag will be set to false. In other words, the only airloop that can have this flag remain True is the last airloop, all others will get reset to false.
  4. This block assumes that the order of OAController is parallel to the order of airloops (AirLoopControlInfo). If the order of the OA controllers in the idf is different from the order of the airloops, then the flags will not be set correctly.
  5. AirLoopDCVFlag is initialized to True. This means that the flag will be true for any airloop that does not have a matching Controller:MechanicalVentilation object. Is this what we want? @rraustad https://github.com/rraustad ?

A pair of defect files have been added which are identical except for the order of the OA controllers. The results in the Outdoor Air Summary table are different - they should be the same.

— Reply to this email directly or view it on GitHub https://github.com/NREL/EnergyPlus/issues/5489.

Richard Raustad Florida Solar Energy Center 1679 Clearlake Road Cocoa, FL 32922 Ph: (321)638-1454 http://www.fsec.ucf.edu/en/

Program Director Electric Vehicle Transportation Center http://evtc.fsec.ucf.edu/

mjwitte commented 8 years ago

@rraustad Basically, if one specifies a DesignSpecification:OutdoorAir object in a VAV terminal unit, and there is not a Controller:MechanicalVentilation, do we want the terminal unit OA calcs to vary based on current occupancy or not?

The I/O Ref for VAV terminal unit says it will always be based on current occupancy (with no mention of checking the Controllcer:MechanicalVentilation DCV input):

1.29.5.21 Field: Design Specification Outdoor Air Object Name This alpha field specifies the name of a DesignSpecification:OutdoorAir object. When this field is used, the terminal unit will increase flow as needed to meet this outdoor air requirement. If Outdoor Air Flow per Person is non-zero, then the outdoor air requirement will be computed based on the current number of occupants in the zone.

Looks like the DCVFlag must have been added later? Checking . . .

mjwitte commented 8 years ago

@rraustad Haven't traced all the way back, but the default for the DCVFlag was flipped to true as part of this OA/DCV Cleanup commit back in v7.0. I guess it makes sense for the terminal unit OA control to follow occupancy by default. It would be much cleaner if that were a field directly in the DesignSpecification:OutdoorAir object or in the terminal unit, instead of being remote in the Controller:MechanicalVentilation object. I realize that's important if the central OA controller and the terminal units are to agree on the total OA required, but that's for another day.

rraustad commented 8 years ago

Sorry, I'm working on something else right now. I was going to suggest that the TU should follow occupancy, otherwise it's just a minimum stop. I also think a switch to follow occupancy or not wouldn't hurt (default=follow). If the MechVent/TU object must read a design spec object then it might make sense to move it there.

On 2/17/2016 10:36 AM, Michael J. Witte wrote:

@rraustad https://github.com/rraustad Haven't traced all the way back, but the default for the DCVFlag was flipped to true as part of this back in v7.0. I guess it makes sense for the terminal unit OA control to follow occupancy by default. It would be much cleaner if that were a field directly in the DesignSpecification:OutdoorAir object or in the terminal unit, instead of being remote in the Controller:MechanicalVentilation object. I realize that's important if the central OA controller and the terminal units are to agree on the total OA required, but that's for another day.

— Reply to this email directly or view it on GitHub https://github.com/NREL/EnergyPlus/issues/5489#issuecomment-185258283.

Richard Raustad Florida Solar Energy Center 1679 Clearlake Road Cocoa, FL 32922 Ph: (321)638-1454 http://www.fsec.ucf.edu/en/

Program Director Electric Vehicle Transportation Center http://evtc.fsec.ucf.edu/

JasonGlazer commented 8 years ago

@mjwitte @rraustad The AirLoopDCVFlag is not even used much and is only referenced in DualDuct.cc and SingleDuct.cc in calling CalcDesignSpecificationOutdoorAir() . I am thinking that the code to set that flag should be moved out of GetOAControllerInputs() in MixedAir.cc and into somewhere else. What do you think?

mjwitte commented 8 years ago

I agree that it seems misplaced here.

JasonGlazer commented 8 years ago

@mjwitte Thinking about the general issue that the ordering of objects is impacting the results, maybe we should consider having a "shuffle objects" test. Like reversing design day in steroids, it would take an input file and randomly reorder objects and run it again. Or maybe the test looks specifically at each particular objects that appears more than once in a file and reorders them randomly. The script to do the rearranging would probably not be difficult to write but I am not sure where it would fit in the CI. The fact that input order is having an impact needs to be rectified.

mjwitte commented 8 years ago

@JasonGlazer I'm assuming this is an isolated case of that. It's not a general problem.

JasonGlazer commented 8 years ago

@mjwitte How do you know?

mbadams5 commented 8 years ago

It could be a general problem. Just think about how all objects are stored in Arrays and then those arrays are traversed in order. That might subtlety affect load calculations, sizing calculations, etc. due to slight numerical instability or bugs in code. If the objects are in a different order in the IDF then they are in a different order in the Arrays as well.

It would be interesting to see how large or widespread this issue is though.

JasonGlazer commented 8 years ago

@mjwitte Getting back to the specific issue, do you have any suggestion as to where it would make more sense to locate the code that does this check for the AirLoopDCVFlag?

mjwitte commented 8 years ago

Looks like it should fit in well in this block of InitOAControllers

mjwitte commented 8 years ago

This section is already walking through each OA controller and matching it with an airloop in order to set up output variables. At this point, you could check if the controller has a Controller:MechanicalVentilation object associated with it (OAController.VentMechObjectNum) and if so, check the dcv flag and if it's false, then set the airloop dcvflag to false.

JasonGlazer commented 8 years ago

Thanks that looks like a good spot.

Myoldmopar commented 8 years ago

Closed via #5554