Add Reports to Support createRMD - ruleset model description

[JasonGlazer]

Pull request overview

• Support for the next phase of createRMD development by adding reports and the NFP

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]

Attached table outputs show samples of current iteration of HVAC Topology Reports for various system types.
Currently, the Airloop Supply Side table uses the Component/Parent/Parent2 approach, and the Zone Equipment table uses the Component/Sub-Component/Sub-Sub-Component approach. The createRMD tool reads the json version of the table output, the html version is intended to help the user/reviewer see the overall system arrangement. Comments are requested.
10372-RulesetReports-0404.zip

[rraustad]

This looks OK to me. I see the supply plenum, for 5ZoneSupRetPlenRAB, which connects to the down stream splitter. I have a test file with a splitter that connects to individual zone supply plenums. That config seems to report just fine.

[rraustad]

I do like the stacking shown here with a row for component, then a row for component with sub component, then same with sub-sub component, but it does make for longer tables than necessary. For example, rows 3 and 4 aren't really needed since that same data is repeated in rows 5 and 6.

[mjwitte]

@JasonGlazer Yesterday's merge and repairs are showing 2 integration debug failures. I can look at these next week.