Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Schedule for Minimum Airflow for VAV Boxes #7643

Merged
merged 60 commits into from
Feb 16, 2020

Conversation

Nigusse
Copy link
Contributor

@Nigusse Nigusse commented Dec 5, 2019

Pull request overview

  • This is a new feature / enhancement to VAV single and dual duct air terminals.
  • added a capability to turndown the minimum air flow below the design minimum using new turndown schedule field. The fraction multiplies the design minimum flow rate or the design minimum fraction.
  • this capability was added to the following single and dual duct VAV air terminals:
    • AirTerminal:SingleDuct:VAV:Reheat
    • AirTerminal:SingleDuct:VAV:NoReheat
    • AirTerminal:SingleDuct:VAV:Reheat:VariableSpeedFan
    • AirTerminal:SingleDuct:VAV:HeatAndCool:Reheat
    • AirTerminal:SingleDuct:VAV:HeatAndCool:NoReheat
    • AirTerminal:DualDuct:VAV

Pull Request Author

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)
  • Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
  • Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
  • Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
  • If any diffs are expected, author must demonstrate they are justified using plots and descriptions
  • If changes fix a defect, the fix should be demonstrated in plots and descriptions
  • If any defect files are updated to a more recent version, upload new versions here or on DevSupport
  • If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
  • If structural output changes, add to output rules file and add OutputChange label
  • If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies

Reviewer

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • If branch is behind develop, merge develop and build locally to check for side effects of the merge
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified
  • Check that performance is not impacted (CI Linux results include performance check)
  • Run Unit Test(s) locally
  • Check any new function arguments for performance impacts
  • Verify IDF naming conventions and styles, memos and notes and defaults
  • If new idf included, locally check the err file and other outputs

@Nigusse Nigusse added the NewFeature Includes code to add a new feature to EnergyPlus label Dec 5, 2019
Copy link
Contributor

@mjwitte mjwitte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nigusse This looks good in general. Some comments.

\note values. This field can be used with any of the three "Zone Minimum Air Flow Input Method"
\note Schedule values are fractions, 0.0 to 1.0. This field is intended for use with
\note ASHRAE Standard 170.
\note If this field is left blank, then the operating minimum air flow fraction value is set to 1.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Operating" is a bit confusing here. Even though the other inputs are the "design" minimum, they also are used for operation, and the existing "Minimum Air Flow Fraction Schedule Name" is primarily operational. It's only used for sizing if the other min flow fields are blank. How about "Minimum Air Flow Turndown Schedule Name" or "Minimum Air Flow Adjustment Schedule Name" or ???

Is this adjustment limited to zero to 1.0? Or would an adjustment >1.0 ever be applicable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will use "Minimum Air Flow Turndown Schedule Name" as the new field name but will use "Adjustment" in the description. I am thinking to limit to 0.0 to 1.0. I think users should use the design minimum fraction or the design minimum flow if they desire scale it up.

\note This field is used if the field Zone Minimum Air Flow Input Method is Scheduled
\note Schedule values are fractions, 0.0 to 1.0.
\note If the field Constant Minimum Air Flow Fraction is blank, then the average of the
\note minimum and maximum schedule values is used for sizing normal-action reheat coils.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs to be very clear that this schedule will be multiplied by the new schedule. That's a little confusing. I suppose few users would do that, they'd likely just use the new schedule with a fixed minimum here, but one could use both schedules together.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to add more detailed explanation.

SingleDuct.hh
Modify struct "SysDesignParams" to add two new member variables.

struct SysDesignParams
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to rename this confusing struct SysDesignParams and its associated name Sys.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will take the liberty to rename the struct when I get there. Thanks.


Modify struct "DamperDesignParams" to add new new member variable

struct DamperDesignParams
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I've always found DamperDesignParams and Damper to be confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do.

@Nigusse
Copy link
Contributor Author

Nigusse commented Jan 6, 2020

These variable renaming were suggested during NFP review. Diffs are not expected due to these commits.

@Myoldmopar
Copy link
Member

@mjwitte you seemed to feel pretty good about this earlier on in the development. You have any lingering concerns? If not then if CI is happy once complete this can merge in.

@mjwitte
Copy link
Contributor

mjwitte commented Jan 22, 2020

@Myoldmopar I took a quick look at just the IDD. That much looks good. I'll defer to you on reviewing the rest of this.

@Myoldmopar
Copy link
Member

OK, yeah it'll merge as long as Windows doesn't see anything.

@Myoldmopar
Copy link
Member

@Nigusse I tried to resolve the conflicts in this branch, but they are a little too involved. Can you please pull develop in and resolve them and push back up? Once complete and CI runs again this can go in.

@Nigusse
Copy link
Contributor Author

Nigusse commented Jan 22, 2020

OK, will do.

@Nigusse
Copy link
Contributor Author

Nigusse commented Jan 23, 2020

@Myoldmopar Resolved merge conflict and did cleanup.

@Nigusse
Copy link
Contributor Author

Nigusse commented Feb 10, 2020

@Myoldmopar working to resolve confclit and will push updated branch shortly after local test.

@Myoldmopar
Copy link
Member

@Nigusse we've had a lot of activity today and it has resulted in some conflicts here. I think they are primarily related to the uncontrolled terminal PR. Can you please take a look at the conflicts, and if you have trouble, @mjwitte or I can help get things back in shape. Thanks!

@Nigusse
Copy link
Contributor Author

Nigusse commented Feb 13, 2020

@Myoldmopar Sure, I am working on it. It will be done first thing in the morning.

@Nigusse
Copy link
Contributor Author

Nigusse commented Feb 14, 2020

@Myoldmopar @mjwitte Merged develop into the branch and resolved conflicts.

@Nigusse
Copy link
Contributor Author

Nigusse commented Feb 14, 2020

Run unit test suite locally and all passed.

@Nigusse
Copy link
Contributor Author

Nigusse commented Feb 14, 2020

@mjwitte I am seeing audit diffs that I was not expecting. Comparing this branch to develop I see the following four output variables that must have been removed from develop for "AirTerminal:SingleDuct:ConstantVolume:NoReheat" object:

  • "Zone Air Terminal Sensible Heating Energy"
  • "Zone Air Terminal Sensible Cooling Energy"
  • "Zone Air Terminal Sensible Heating Rate"
  • "Zone Air Terminal Sensible Cooling Rate"

Would you please confirm?

SetupOutputVariable(
"Zone Air Terminal Sensible Heating Rate", OutputProcessor::Unit::W, sd_airterminal(SysNum).HeatRate, "System", "Average", sd_airterminal(SysNum).SysName);
SetupOutputVariable(
"Zone Air Terminal Sensible Cooling Rate", OutputProcessor::Unit::W, sd_airterminal(SysNum).CoolRate, "System", "Average", sd_airterminal(SysNum).SysName);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nigusse These were removed because they duplicate the same outputs that are already set up by the air distribution unit here.

Copy link
Contributor Author

@Nigusse Nigusse Feb 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mjwitte Thanks. I will correct in this branch and push again.

Copy link
Contributor

@mjwitte mjwitte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nigusse I've pushed up a few minor text edits. I've run unit tests locally - all good. I've tested the new schedule with VAVSingleDuctReheat.idf - and it works.

There is no new example file for this. I'm not going to hold this up for that, but we need this somewhere in the testfiles. Perhaps there is an appropriate existing file to add this to (one that would correspond to applying ASHRAE Std 170).

Assuming CI comes back clean, I'll merge this soon.

@mjwitte mjwitte changed the title Scheduling Minimum Airflow for VAV Boxes New Schedule for Minimum Airflow for VAV Boxes Feb 14, 2020
@mjwitte
Copy link
Contributor

mjwitte commented Feb 14, 2020

@Nigusse Also - have you tested this with each of the affected terminal unit types?

@mjwitte mjwitte merged commit c771fa8 into develop Feb 16, 2020
@mjwitte mjwitte deleted the Scheduling-Min-AirFlow-For-VAV-Boxes branch February 16, 2020 04:33
@Nigusse
Copy link
Contributor Author

Nigusse commented Feb 16, 2020

@mjwitte Yes, I have tested each combination. Also each combination has appropriate unit test. We can always add this new schedule field to selected existing test files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Development

Successfully merging this pull request may close these issues.

8 participants