Obtain same results with and without EMS Construction:ComplexFenestrationState

[lgu1234]

Pull request overview

Same results are obtained from two input files. One file has a specific window construction, and the other file uses EMS construction to switch it to the same window construction. Two changes are made:

1. EMS calling point should be BeginZoneTimestepBeforeInitHeatBalance, instead of BeginZoneTimestepBeforePredictor, because construction state change occurs in InitHeatBalance.

2. Activate construction state change after the calling point immediately.

Upload 4 set of test files.
The user provided 3 set of test file. I converted them into Version 9.3
inS.idf (same results)
inCFS11 (same results)
inCFS1.idf (calling point of BeginZoneTimestepBeforePredictor with differences)
CFS2.idf (same results)
Tiny differences were found by running EMSThermochromicWindow.idf.

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

[Myoldmopar]

The fact that you are able to see agreeing results now is promising. I'm going to build locally with develop pulled in and verify.

[Myoldmopar]

Reorder, no problem.

[Myoldmopar]

OK, so this just catches all windows ahead of time and sets the checked/OK flags to true prior to the block under it. In the original case, I guess the windows would sometimes get to this point with these flags set to false. Fine with me.

[Myoldmopar]

Pulled develop back in locally and rebuilt and retested. Still passed and looked good. I'm going to merge this. Thanks @lgu1234.