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

Fix #9331 - Crash if window construction is zero due to bad construction name #9646

Merged
merged 5 commits into from
Sep 15, 2022

Conversation

jmarrec
Copy link
Contributor

@jmarrec jmarrec commented Sep 6, 2022

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

```shell
[ RUN      ] EnergyPlusFixture.Wrong_Window_Construction
energyplus_tests: /home/julien/Software/Others/EnergyPlus/third_party/ObjexxFCL/src/ObjexxFCL/Array1.hh:861: T& ObjexxFCL::Array1< <template-parameter-1-1> >::operator()(int) [with T = EnergyPlus::Construction::ConstructionProps]: Assertion `contains( i )' failed.
```

backtrace:

```shell
frame #5: 0x00005555632f28ca energyplus_tests`EnergyPlus::SurfaceGeometry::CheckWindowShadingControlFrameDivider(state=0x000055556dc601b0, cRoutineName=(_M_len = 19, _M_str = "GetHTSubSurfaceData"), ErrorsFound=0x00007fffffffb8e6, SurfNum=2, FrameField=6) at SurfaceGeometry.cc:5972:106
   5969	            }                     // End of check if window has a construction
   5970	        }
   5971	
-> 5972	        if (state.dataConstruction->Construct(state.dataSurfaceGeometry->SurfaceTmp(SurfNum).Construction).WindowTypeEQL) {
   5973	            if (state.dataSurfaceGeometry->SurfaceTmp(SurfNum).FrameDivider > 0) {
   5974	                // Equivalent Layer window does not have frame/divider model
   5975	                ShowSevereError(state
```
@jmarrec jmarrec added the Defect Includes code to repair a defect in EnergyPlus label Sep 6, 2022
@jmarrec jmarrec self-assigned this Sep 6, 2022
ErrorsFound = true;
continue;
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't have a problem with using a continue when "very" severe errors are found. But I wonder if there are some errors that won't show up until the user fixes the first one found. It may not be necessary to continue on some of these warnings so that as many warnings could be reported the first time through. Which one of these input errors actually causes the crash?

Copy link
Member

Choose a reason for hiding this comment

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

I understand the sentiment here. If we could issue all 3 errors up front on the subsurface, it would be good to let the user know all 3 errors right away. Otherwise they will end up possibly running 3 iterations to solve all the issues. But I also understand the idea of wanting to avoid issues from subsequent checking. I could be swayed either way. Perhaps some extra description of the exact errors we are bypassing by each continue would help.

Copy link
Contributor Author

@jmarrec jmarrec Sep 15, 2022

Choose a reason for hiding this comment

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

I am perfectly fine if we revert dcbda05, the 59f5c65 is enough to avoid the crash

Copy link
Contributor Author

@jmarrec jmarrec Sep 15, 2022

Choose a reason for hiding this comment

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

Side note: I actually have a stashed commit that went even further and wrapped every GetXXX call inside an if (!ErrorsFound) so it'll bail early here:

GetDetShdSurfaceData(state, ErrorsFound, NumSurfs, TotDetachedFixed, TotDetachedBldg);
GetRectDetShdSurfaceData(state, ErrorsFound, NumSurfs, TotRectDetachedFixed, TotRectDetachedBldg);
GetHTSurfaceData(state,
ErrorsFound,
NumSurfs,
TotHTSurfs,
TotDetailedWalls,
TotDetailedRoofs,
TotDetailedFloors,
state.dataSurfaceGeometry->BaseSurfCls,
state.dataSurfaceGeometry->BaseSurfIDs,
NeedToAddSurfaces);
GetRectSurfaces(state,
ErrorsFound,
NumSurfs,
TotRectExtWalls,
TotRectIntWalls,
TotRectIZWalls,
TotRectUGWalls,
TotRectRoofs,
TotRectCeilings,
TotRectIZCeilings,
TotRectGCFloors,
TotRectIntFloors,
TotRectIZFloors,
state.dataSurfaceGeometry->BaseSurfIDs,
NeedToAddSurfaces);
GetHTSubSurfaceData(state,
ErrorsFound,
NumSurfs,
TotHTSubs,
state.dataSurfaceGeometry->SubSurfCls,
state.dataSurfaceGeometry->SubSurfIDs,
AddedSubSurfaces,
NeedToAddSubSurfaces);
GetRectSubSurfaces(state,
ErrorsFound,
NumSurfs,
TotRectWindows,
TotRectDoors,
TotRectGlazedDoors,
TotRectIZWindows,
TotRectIZDoors,
TotRectIZGlazedDoors,
state.dataSurfaceGeometry->SubSurfIDs,
AddedSubSurfaces,
NeedToAddSubSurfaces);
GetAttShdSurfaceData(state, ErrorsFound, NumSurfs, TotShdSubs);
GetSimpleShdSurfaceData(state, ErrorsFound, NumSurfs, TotOverhangs, TotOverhangsProjection, TotFins, TotFinsProjection);
GetIntMassSurfaceData(state, ErrorsFound, NumSurfs);
state.dataSurface->TotSurfaces = NumSurfs + AddedSubSurfaces + NeedToAddSurfaces + NeedToAddSubSurfaces;
if (ErrorsFound) {
ShowFatalError(state, std::string{RoutineName} + "Errors discovered, program terminates.");
}

Copy link
Member

Choose a reason for hiding this comment

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

@jmarrec I think I will take the offer of just reverting the commit. That will allow the fix to go in without having to worry about this new pattern. I'll revert and test it out locally to make sure, then push it up and get this merged.

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.

Not marking this approved or not yet, I need to think about it a bit more.

ErrorsFound = true;
continue;
Copy link
Member

Choose a reason for hiding this comment

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

I understand the sentiment here. If we could issue all 3 errors up front on the subsurface, it would be good to let the user know all 3 errors right away. Otherwise they will end up possibly running 3 iterations to solve all the issues. But I also understand the idea of wanting to avoid issues from subsequent checking. I could be swayed either way. Perhaps some extra description of the exact errors we are bypassing by each continue would help.

" ..... Reference severe error count=1",
" ..... Last severe error=FenestrationSurface:Detailed=\"SURFACE 8 - TRIANGULARWINDOW\", invalid Construction Name=\"WRONG CONSTRUCTION\".",
});
EXPECT_TRUE(compare_err_stream(error_string, true));
Copy link
Member

Choose a reason for hiding this comment

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

👍

@jmarrec jmarrec added this to the EnergyPlus 22.2 milestone Sep 15, 2022
@Myoldmopar
Copy link
Member

Everything happy after reverting that. We can certainly discuss the idea of early exits, but for now this is a nice minimal change plus test. Thanks!

@Myoldmopar
Copy link
Member

Not waiting on any CI to run this, merging it in.

@Myoldmopar Myoldmopar merged commit 055c562 into develop Sep 15, 2022
@Myoldmopar Myoldmopar deleted the 9331_Crash_Wrong_Window_Construction branch September 15, 2022 19:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Defect Includes code to repair a defect in EnergyPlus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Crash if window construction is zero due to bad construction name
7 participants