Skip to content

Add a new field of Per Person Ventilation Rate Mode to AirTerminal:SingleDuct:Uncontrolled and AirTerminal:SingleDuct:Mixer#6252

Merged
rraustad merged 2 commits intodevelopfrom
150233856-Add-a-new-field-of-Per-Person-Ventilation-Rate-Mode
Aug 18, 2017
Merged

Add a new field of Per Person Ventilation Rate Mode to AirTerminal:SingleDuct:Uncontrolled and AirTerminal:SingleDuct:Mixer#6252
rraustad merged 2 commits intodevelopfrom
150233856-Add-a-new-field-of-Per-Person-Ventilation-Rate-Mode

Conversation

@lgu1234
Copy link
Copy Markdown
Contributor

@lgu1234 lgu1234 commented Aug 17, 2017 •
edited by rraustad
Loading

Pull request overview

A new field was added to enhance both terminal units types of AirTerminal:SingleDuct:Uncontrolled and AirTerminal:SingleDuct:Mixer. The ventilation rate determined by the Outdoor Air Flow per Person input in DesignSpecification:OutdoorAir can be varied by choosing either CurrentOccupancy or DesignOccupancy in the Per Person Ventilation Rate Mode field.

Work Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

  • Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
  • At least one of the following appropriate labels must be added to this PR to be consumed into the changelog:
    • Defect: This pull request repairs a github defect issue. The github issue should be referenced in the PR description
    • Refactoring: This pull request includes code changes that don't change the functionality of the program, just perform refactoring
    • NewFeature: This pull request includes code to add a new feature to EnergyPlus
    • Performance: This pull request includes code changes that are directed at improving the runtime performance of EnergyPlus
    • DoNoPublish: This pull request includes changes that shouldn't be included in the changelog

Review Checklist

This will not be exhaustively relevant to every PR.

  • Code style (parentheses padding, variable names)
  • Functional code review (it has to work!)
  • If defect, results of running current develop vs this branch should exhibit the fix
  • CI status: all green or justified
  • Performance: CI Linux results include performance check -- verify this
  • Unit Test(s)
  • C++ checks:
    • Argument types
    • If any virtual classes, ensure virtual destructor included, other things
  • IDD changes:
    • Verify naming conventions and styles, memos and notes and defaults
    • Open windows IDF Editor with modified IDD to check for errors
    • If transition, add rules to spreadsheet
    • If transition, add transition source
    • If transition, update idfs
  • If new idf included, locally check the err file and other outputs
  • Documentation changes in place
  • Changed docs build successfully
  • ExpandObjects changes?
  • If output changes, including tabular output structure, add to output rules file for interfaces

@rraustad rraustad added IDDChange Code changes impact the IDD file (cannot be merged after IO freeze) NewFeature Includes code to add a new feature to EnergyPlus labels Aug 17, 2017
@rraustad
Copy link
Copy Markdown
Collaborator

rraustad commented Aug 17, 2017

So why are we adding a new field to zone equipment instead of adding the new field to the DesignSpecification:OutdoorAir object? Then everyone would have access to that information instead of just TUs.

@mjwitte
Copy link
Copy Markdown
Contributor

mjwitte commented Aug 17, 2017

@rraustad Well, both approaches were discussed. We opted for this one because it follow the precedent already present in AirTerminal:DuaDuct:VAV:OutdoorAir and it avoids confusion at the system OA controller level. This clearly applies to just this terminal unit. A bit ugly, yeah, but safe.

@rraustad
Copy link
Copy Markdown
Collaborator

rraustad commented Aug 18, 2017

OK, that makes sense. But thinking out loud, if one TU wanted to use the people schedule, doesn't that mean the OA controller would also use the schedule? I guess not but it's a little strange for the OA controller doing something different than the TU. Or if one TU wanted to use max occupancy, and another wanted to use the schedule, then what would the OA controller need to do? How would the OA controller know how much OA to bring in? Yes, this can get very messy. So worst case, the OA controller could ask each TU how much OA it needed. I guess then OK for now until we get more comfortable with how this plays out.

@lgu1234 lgu1234 changed the title Upload a new feature Add a new field of Per Person Ventilation Rate Mode to AirTerminal:SingleDuct:Uncontrolled and AirTerminal:SingleDuct:Mixer Aug 18, 2017
@rraustad
Copy link
Copy Markdown
Collaborator

rraustad commented Aug 18, 2017

There are no diff's with this change and the warning was already fixed. This appears to do what is expected.

@rraustad rraustad merged commit 6cb7859 into develop Aug 18, 2017
@rraustad
Copy link
Copy Markdown
Collaborator

rraustad commented Aug 18, 2017

Reviewed and merged.

@rraustad rraustad deleted the 150233856-Add-a-new-field-of-Per-Person-Ventilation-Rate-Mode branch August 18, 2017 18:15
@rraustad rraustad mentioned this pull request Aug 21, 2017
Closed
3 tasks
@mjwitte mjwitte mentioned this pull request Sep 13, 2017
Closed
3 tasks
@mjwitte mjwitte mentioned this pull request Sep 20, 2017
Merged
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

IDDChange Code changes impact the IDD file (cannot be merged after IO freeze) NewFeature Includes code to add a new feature to EnergyPlus

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@lgu1234 @rraustad @mjwitte @nrel-bot @nrel-bot-2 @nrel-bot-3