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

A new algorithm for polygon clipping in solar calculations for rectangular surfaces #7574

Merged
merged 11 commits into from
Feb 19, 2020

Conversation

xuanluo113
Copy link
Contributor

Pull request overview

There exists an extensive amount of literature on polygon clipping when constrained to rectangular surfaces. The current polygon clipping method implemented in EnergyPlus, using the Sutherland-Hodgman algorithm, is a performance hotspot. The method is generalized for clipping area of all shapes, but in EnergyPlus simulations runs, are often called with only rectangular surfaces.

We propose a negligible amount of code to check if the clipping surface is rectangular. And if so,
we redirect to a new method using the Slater & Barsky algorithm.

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

@xuanluo113 xuanluo113 added NewFeature Includes code to add a new feature to EnergyPlus Performance Includes code changes that are directed at improving the runtime performance of EnergyPlus labels Oct 21, 2019
@xuanluo113 xuanluo113 added this to the EnergyPlus Future milestone Oct 21, 2019
@xuanluo113 xuanluo113 self-assigned this Oct 21, 2019
@nrel-bot
Copy link

nrel-bot commented Dec 9, 2019

@XuanLuoLBL @lgentile it has been 28 days since this pull request was last updated.

1 similar comment
@nrel-bot
Copy link

nrel-bot commented Jan 6, 2020

@XuanLuoLBL @lgentile it has been 28 days since this pull request was last updated.

@mjwitte mjwitte added the IDDChange Code changes impact the IDD file (cannot be merged after IO freeze) label Jan 13, 2020
@mjwitte
Copy link
Contributor

mjwitte commented Jan 13, 2020

@XuanLuoLBL This needs a unit test, please. Once that's in, please request a reviewer here in the PR.

@mjwitte
Copy link
Contributor

mjwitte commented Jan 13, 2020

@XuanLuoLBL Needs doc updates, also.

@xuanluo113
Copy link
Contributor Author

@XuanLuoLBL This needs a unit test, please. Once that's in, please request a reviewer here in the PR.

@mjwitte This branch is also ready for review, as I added those unit tests and documentation.

@xuanluo113
Copy link
Contributor Author

@Myoldmopar Edwin, this branch is ready for review. Would you please suggest reviewers? Thanks.

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.

@xuanluo113 I've reviewed the idd and documentation changes. Comments below.
@Myoldmopar I've done a cursory review of the new code. Would like your eyes on this also.

tst/EnergyPlus/unit/SolarShading.unit.cc Outdated Show resolved Hide resolved
tst/EnergyPlus/unit/SolarShading.unit.cc Show resolved Hide resolved

inline void CLIPLINE(Real64 &x1, Real64 &x2, Real64 &y1, Real64 &y2,
Real64 maxX, Real64 minX, Real64 maxY, Real64 minY, bool &visible, bool &rev) {
// SLATER & BARSKY 1994
Copy link
Contributor

Choose a reason for hiding this comment

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

A more complete citation would be good here. And the new functions should have at least a couple of comment lines stating what they do.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, this looks fine, but the citation is important. The CLIPLINE and CLIPRECT function names look suspiciously like they were taken from some FORTRAN source. Can you verify where this exact code came from? Also I'm not sure you're going to gain anything by trying to inline this massive function filled with logic.

Copy link
Contributor Author

@xuanluo113 xuanluo113 Feb 18, 2020

Choose a reason for hiding this comment

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

@Myoldmopar @mjwitte I added the references and am trying to add line comments. I don't think it's borrowed code. It should be based on the algorithm introduced in the paper mimicking the Fortran naming style of other functions.

HCX[l1 + 2] == HCX[l1 + 3]) ||
((((HCY[l1] == HCY[l1 + 1] && HCX[l1] != HCX[l1 + 1]) &&
(HCX[l1 + 2] == HCX[l1 + 1] && HCX[l1 + 3] == HCX[l1])) &&
(HCY[l1 + 2] == HCY[l1 + 3]))))));
Copy link
Contributor

Choose a reason for hiding this comment

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

This is hard to read. Apply formatting? Also, seems it would be more efficient to move (NV2==4) to an if block wrapping this so there's no need to check the other conditions if NV2<>4.

Copy link
Member

Choose a reason for hiding this comment

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

As an FYI, native C++ operators will short circuit, so if NV2 is not 4, it will not evaluate the rest of this. But that said, yeah, this is a big messy expression. I would create three individual terms:

bool const numVertsIs4 = NV2 == 4;
bool const term1 = blah;
bool const term2 = blah;
rectFlat = numVertsIs4 || term1 || term2;

Of course better naming but that would at least make the logic here tractable.

@mjwitte
Copy link
Contributor

mjwitte commented Feb 14, 2020

@xuanluo113 Be sure to pull this branch before making additional changes. I merged in develop yesterday and fixed the unit tests for the new eio file stuff.

Copy link
Member

@Myoldmopar Myoldmopar left a comment

Choose a reason for hiding this comment

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

I made a few comments that should at least be discussed, and maybe requires some code changes.

HCX[l1 + 2] == HCX[l1 + 3]) ||
((((HCY[l1] == HCY[l1 + 1] && HCX[l1] != HCX[l1 + 1]) &&
(HCX[l1 + 2] == HCX[l1 + 1] && HCX[l1 + 3] == HCX[l1])) &&
(HCY[l1 + 2] == HCY[l1 + 3]))))));
Copy link
Member

Choose a reason for hiding this comment

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

As an FYI, native C++ operators will short circuit, so if NV2 is not 4, it will not evaluate the rest of this. But that said, yeah, this is a big messy expression. I would create three individual terms:

bool const numVertsIs4 = NV2 == 4;
bool const term1 = blah;
bool const term2 = blah;
rectFlat = numVertsIs4 || term1 || term2;

Of course better naming but that would at least make the logic here tractable.


inline void CLIPLINE(Real64 &x1, Real64 &x2, Real64 &y1, Real64 &y2,
Real64 maxX, Real64 minX, Real64 maxY, Real64 minY, bool &visible, bool &rev) {
// SLATER & BARSKY 1994
Copy link
Member

Choose a reason for hiding this comment

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

Yeah, this looks fine, but the citation is important. The CLIPLINE and CLIPRECT function names look suspiciously like they were taken from some FORTRAN source. Can you verify where this exact code came from? Also I'm not sure you're going to gain anything by trying to inline this massive function filled with logic.

src/EnergyPlus/SolarShading.cc Outdated Show resolved Hide resolved
@xuanluo113
Copy link
Contributor Author

@Myoldmopar @mjwitte I've addressed all comments except for the coding style and comment ones for the two newly added solar clipping functions. Still working on this.

@Myoldmopar
Copy link
Member

Regressions locally look all clean, just eio diffs. I'm merging this.

@Myoldmopar Myoldmopar merged commit 14cf41f into develop Feb 19, 2020
@Myoldmopar Myoldmopar deleted the shadow-clip branch February 19, 2020 21:59
@xuanluo113
Copy link
Contributor Author

Regressions locally look all clean, just eio diffs. I'm merging this.

thanks.

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 Performance Includes code changes that are directed at improving the runtime performance of EnergyPlus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants