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

Streamline CalcMoreNodeInfo #10520

Draft
wants to merge 3 commits into
base: develop
Choose a base branch
from
Draft

Streamline CalcMoreNodeInfo #10520

wants to merge 3 commits into from

Conversation

mjwitte
Copy link
Contributor

@mjwitte mjwitte commented May 23, 2024

Pull request overview

  • Streamline CalcMoreNodeInfo to avoid unnecessary checking of various node calc flags if none of the extra node outputs have been requested (wetbulb, RH, dewpoint, and specific heat).
  • Move several loose arrays in NodeInputManager to be members of MoreNodeData.

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 defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • 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

@mjwitte mjwitte added the Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring label May 23, 2024
@nrel-bot-3
Copy link

@mjwitte @Myoldmopar it has been 28 days since this pull request was last updated.

state, thisNode.Temp, thisNode.HumRat, state.dataEnvrn->OutBaroPress, thisMoreNodeInfo.reportingString);
} else {
thisMoreNodeInfo.WetBulbTemp = 0.0;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Aren't these already initialized to 0? Why set this again?

struct MoreNodeData
{
    Real64 WetBulbTemp = 0.0; 

thisMoreNodeInfo.ReportEnthalpy = Cp * thisNode.Temp;
thisMoreNodeInfo.SpecificHeat = Cp; // always fill since cp already always being calculated anyway
// thisMoreNodeInfo.WetBulbTemp = 0.0; for water nodes, initialized to zero
thisMoreNodeInfo.RelHumidity = 100.0;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need to set this for a water node? Could initialize all to 100 if necessary? Or 1-time loop just for water nodes? Maybe not worth it.

@mjwitte
Copy link
Contributor Author

mjwitte commented Jul 2, 2024

@rraustad Agreed. No reason to keep setting either of these to the same constant value every timestep.

@nrel-bot
Copy link

@mjwitte @Myoldmopar it has been 28 days since this pull request was last updated.

1 similar comment
@nrel-bot-2c
Copy link

@mjwitte @Myoldmopar it has been 28 days since this pull request was last updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants