Pull request overview

• This PR aims to convert the goto statements in the physics-based VRF model to use more standard while or do-while loops.

pattern 1

The following table shows some pseudo-code of the current goto example in the physics-based VRF model (column 1) and standard while and do-while loops (columns 2 and 3). To simplify the reasoning of its execution, I simplified the operations into letters and will check what type of regex they each produce.

A = stuff A, B = stuff B and counter increment, C being the condition check

For this pattern of existing code. I'll try to hoist the "stuff B" part out of the if branch and have an intermediate step

    label:
        stuff A
        evaluate condition (in case stuff overwrites variables used in it)
        stuff B
    if (condition) {
        goto label
    }

Then this can be converted to a do-while loop

    do {
        stuff A
        evaluate condition (in case stuff overwrites variables used in it)
        stuff B
    } while (condition)

suppose D = evaluate condition (in case stuff overwrites variables used in it), then both the intermediate and final step evaluates to (ADBC)+

If A and B are the things that matter most, than the original version of code will execute to A(BA)*, and the new code will execute to (AB)+, with a trailing B comparing with the original code. If this additional B doesn't impact the result, then this could be a way to transition such a pattern of goto to a standard while loop.

Otherwise, the following should be used, which evaluates to ADC(BCADC)*. If D and C doesn't change the behavior, then it evaluates to A(BA)*

    do {
        stuff A
        evaluate condition (in case stuff overwrites variables used in it)
        if (condition) {
            stuff B
        }
    } while (condition)

pattern 2

goto jumps out two or more levels, like in label23 in HVACVariableRefrigerantFlow.cc.

Label:;
stuff A
if (C) {
    stuff E
} else {
    stuff F
    if (D) {
        stuff B
        goto label
    }
    stuff G
}

This can be converted to a do-while loop as follows

do {
    stuff A
    if (C) {
        stuff E
        break
    } else {
        stuff F
        if (D) {
            stuff B
        } else {
            stuff G
            break
        }
    }
} while (D)

In both cases, the following is what it evaluates to for different combination of C and D

C true  D true:  ACE
C true  D false: ACE
C false D true:  (ACFDB)+ACFDG
C false D false: ACFDG

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