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

Allow edges to have same surface on both sides #5003

Merged
merged 6 commits into from
Oct 30, 2023
Merged

Conversation

macumber
Copy link
Contributor

Pull request overview

Supports polygons with interior holes cut out with reverse winding, this fixes a regression from 3.6.0 that was discovered in 3.7.0-rc1.

Pull Request Author

No API or IDD changes needed

Labels:

  • If change to an IDD file, add the label IDDChange
  • If breaking existing API, add the label APIChange
  • If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • Code Style, strip trailing whitespace, etc.
  • All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
  • Labeling is ok
  • 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

@jmarrec jmarrec added component - Utilities Geometry Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge. labels Oct 29, 2023
Copy link
Collaborator

@jmarrec jmarrec left a comment

Choose a reason for hiding this comment

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

Just going to make a dumb change to retrigger a CI pass

src/utilities/geometry/Polyhedron.cpp Outdated Show resolved Hide resolved
@jmarrec
Copy link
Collaborator

jmarrec commented Oct 29, 2023

@macumber thanks for the fix. I wonder if we shouldn't just erase these edges in the polyhedron instead of retaining them and putting them being shared twice to the same surface. Have you tried it by any chance?

Edit: I toyed with the idea of removing them directly in Surface3d 's ctor, but that doesn't work because the Surface3d isn't convex in that case

Tried implementation, at end of current Ctor:

  // #5002 - special case to find and remove edges that are used to "cut" in to a surface to remove an interior hole
  const bool keep_edge = true;
  std::vector<bool> mask = std::vector<bool>(edges.size(), keep_edge);
  for (size_t i = 0; i < edges.size() - 1; ++i) {
    for (size_t j = i + 1; j < edges.size(); ++j) {
      if (edges[i].reverseEqual(edges[j])) {
        mask.at(i) = false;
        mask.at(j) = false;
      }
    }
  }
  edges.erase(std::remove_if(edges.begin(), edges.end(), [this, &mask](const auto& edge) { return mask.at(&edge - edges.data()); }), edges.end());

Comment on lines 276 to 277
for (size_t i = 0; i < edges.size(); ++i) {
for (size_t j = 0; j < edges.size(); ++j) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know I'm guilty here because I've done it a couple of lines above when looping on surfaces, but we can avoid traversing that much by just doing combinations (instead of permutations)

Suggested change
for (size_t i = 0; i < edges.size(); ++i) {
for (size_t j = 0; j < edges.size(); ++j) {
for (size_t i = 0; i < edges.size() - 1; ++i) {
for (size_t j = i + 1; j < edges.size(); ++j) {

@jmarrec
Copy link
Collaborator

jmarrec commented Oct 30, 2023

I guess I botched something in f2c2537 since tests are failing now, but I can't see what I did wrong right now...

@jmarrec
Copy link
Collaborator

jmarrec commented Oct 30, 2023

Ok I see.

auto ospace3 = model2->getConcreteModelObjectByName<Space>("Shading_Surface_Group_1");
ASSERT_TRUE(ospace3);
EXPECT_EQ(0.0, ospace3->volume());
EXPECT_TRUE(ospace3->isVolumeAutocalculated());

This has zero surfaces.

So the loop goes: for (size_t i = 0; i < -1; ++i), size_t is an unsigned and static_cast<size_t>(-1) ==. 18446744073709551615

static_cast<size_t>(-1) is a very large unsigned number.
We'll just be iterating an integer once too many time, which is totally unoticable
@jmarrec jmarrec merged commit b36c283 into NREL:develop Oct 30, 2023
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component - Utilities Geometry Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

v370-rc1 : too stringent polyhedron checks?
3 participants