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.

Sign up for GitHub

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

Jump to bottom

Remove Unused Var6 from PerformanceCurveObject #8798

Merged
merged 1 commit into from
Jun 21, 2021
Merged

Remove Unused Var6 from PerformanceCurveObject #8798

merged 1 commit into from
Jun 21, 2021

Conversation

mitchute
Copy link
Collaborator

@mitchute mitchute commented Jun 2, 2021

Pull request overview

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

@mitchute mitchute added the Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring label Jun 2, 2021
@mitchute mitchute added this to the EnergyPlus 9.6 Release milestone Jun 2, 2021
@mitchute mitchute self-assigned this Jun 2, 2021
mitchute
mitchute commented Jun 2, 2021
View reviewed changes
Copy link
Collaborator Author

@mitchute mitchute left a comment •
edited
Loading

Choose a reason for hiding this comment

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

Is this all we need to do here? I can probably add some unit tests since I'm guessing we may not have full coverage on this, but is this the extent of what this was intended to fix?

It seems dangerous that we are allowing 6 vars to be passed into CurveValue, then switching inside based on whether we have a curve or a table, which respectively accept 5 or 6 vars. Maybe we need a check, but by that point, it's probably just as efficient to optionally pass the 6th var rather than hitting a check every time.

I'm open to suggestions on this.

src/EnergyPlus/CurveManager.cc
Comment on lines +198 to 209
switch (state.dataCurveManager->PerfCurve(CurveIndex).InterpolationType) {
case InterpTypeEnum::EvaluateCurveToLimits: {
CurveValue = PerformanceCurveObject(state, CurveIndex, Var1, Var2, Var3, Var4, Var5);
break;
}
case InterpTypeEnum::BtwxtMethod: {
CurveValue = BtwxtTableInterpolation(state, CurveIndex, Var1, Var2, Var3, Var4, Var5, Var6);
break;
}
default:
ShowFatalError(state, "CurveValue: Invalid Interpolation Type");
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Changed this from an IF/ELSE to a switch block since we already have enums.

src/EnergyPlus/CurveManager.cc
}
switch (state.dataCurveManager->PerfCurve(CurveIndex).InterpolationType) {
case InterpTypeEnum::EvaluateCurveToLimits: {
CurveValue = PerformanceCurveObject(state, CurveIndex, Var1, Var2, Var3, Var4, Var5);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Var6 was removed.

@Myoldmopar
Copy link
Member

I'm on board here, this is good. Building and testing locally with develop pulled in.

@shorowit
Copy link
Contributor

Am I interpreting the results correctly that this increased runtime by 3%?

@mitchute
Copy link
Collaborator Author

mitchute commented Jun 21, 2021 •
edited
Loading

I think it's 0.3%. Also, I believe the baseline has moved down, so this is up from a relative perspective. At least for my PR's, #8818 and #8819 should both have resulted in improved performance, but this branch doesn't have those changes merged in.

@mitchute
Copy link
Collaborator Author

Oh wait, sorry. That SHA is from 19 days ago. I'm not sure what the issue would be then.

@shorowit
Copy link
Contributor

Oh, you're right, it does say -0.3%. Huh. I must have misread it.

@Myoldmopar
Copy link
Member

One thing: the entire set of Github-Pages backed posts are rebuilt every time the CI dashboard rebuilds. So IIUC, the performance numbers there will reflect an updated baseline, which now includes a bunch of other stuff, some of which had significant improvements in runtime.

Two things: We need to keep in mind that the performance values on there are good for throwing up warning flags if some refactor or new feature inadvertently increases runtime. But it's not a direct representation of wall time. We actually have a plan starting to get worked up for how to better represent actual wall time in a reliable, repeatable way, but it's not ready yet.

Three things, ah ah ah; on this particular PR, it's quite obvious that nothing was done to increase runtime. This reduced a variable that was simply in the way and I cannot fathom how it could've increased runtime. I pulled develop in locally and built and ran the full integration and unit test suite. All is well. Merging this in. Thanks @mitchute !

@Myoldmopar Myoldmopar merged commit 1a0c04f into develop Jun 21, 2021
@Myoldmopar Myoldmopar deleted the remove-unused-var6-from-performancecurveobject branch June 21, 2021 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@mitchute mitchute

Labels
Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring
Projects
None yet
Milestone
EnergyPlus 9.6 Release
Development

Successfully merging this pull request may close these issues.

Remove unused Var6 in curve function
8 participants
@mitchute @Myoldmopar @shorowit @nrel-bot @nrel-bot-2 @nrel-bot-3 @nrel-bot-2b @nrel-bot-2c