Produce Convexity Check Warning Only When Appropriate

[RKStrand]

Pull request overview

• Fixes CheckConvexity throws Surface is Non-Convex warnings regardless of ShadowCalculation settings #10299
• The convexity check is only supposed to throw a warning message when the Polygon Clipping Algorithm is employed with the ConvexWeilerAtherton algorithm for shading. Previously, this was being produced for Pixel Counting and other shading algorithms inappropriately. The code was modified to match the intent of the documentation and the warning messages being produced by the code. The solution required that the get routine for the Shadowing Calculation input be separated from some of the processing that is done and the get routine had to be moved up in the order of simulation. After the fix, the only differences in the results are a change in order of a couple of lines in the EIO file (change in order, not in values in the report). All other output is identical to before the fix as anticipated. Six new unit tests look at various combinations of input to make sure things are being read in and set properly.

NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE

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]

Seems odd that all of these shading variables are in DataSystemVariables instead of SolarShading. I'm not suggesting you have to move these in this PR, but 'zoneName' needs to be more specific, like shadingGroupZoneListNames.

Also, if you make this a std::vector and push to it when reading the input, then you can use it's size and drop shadingGroupsNum.

[RKStrand]

Yeah, I don't know why these are in DataSystemVariables and not SolarShading. I guess I was looking to solve the problem and wasn't too concerned about the location of the variables (thought there must have been some reason--probably not a great assumption).

So, just to clarify and get this to move forward...you would like to see the zoneName changed to shadingGroupZoneListNames. You would also like to see this converted to a vector as part of this work?

[mjwitte]

So, just to clarify and get this to move forward...you would like to see the zoneName changed to shadingGroupZoneListNames.

Yes, please.

You would also like to see this converted to a vector as part of this work?

That's up to you for this PR.

[RKStrand]

Variable name change made in the latest commit. Hopefully the ci comes back with all green as before.

[RKStrand]

Ok, after some back and forth and some weird goings on yesterday, the variable name change has been made and ci is coming back like it should with only the EIO changes (only changes in the info location--values the same). All good?

[mjwitte]

I know this is existing code, and it's not a frequently used option, but this could be so much more efficient. Instead of looping through all of the zonegroups for each surface, this could simply go through the zones in each zonelist and loop over the exterior surrfaces in each zone (Zone.vZoneHTSurfaceList). Mostly just noting this here, since this seemingly simple fix has already had a lot of scope creep.

[RKStrand]

I agree that this would be much more efficient. I'd like to have us make a mental note of this and deal with it at a later date if you are okay with that. I wonder if there are more places where we could be much more efficient and we don't even realize it. If only we all had the time to do that sort of efficiency review in the code...

[Myoldmopar]

I'm fine with holding off on the efficiency refactor that was brought up by @mjwitte. Let's just try to get this merged if it's ready. I'll test it out.

[Myoldmopar]

Yeah, it's all testing fine, and CI is all happy. I'll merge this one. Thanks @RKStrand