Fix 9-3-0 to 9-4-0 transition for objects that accept report variable or meter name

[dareumnam]

Pull request overview

• Fixes 9.4 Transition Issue #8362
• In objects that accept report variable or meter name(Meter:Custom, Meter:CustomDecrement, EnergyManagementSystem:Sensor, DemandManagerAssignmentList, ElectricLoadCenter:Tranasformer, ElectricLoadCenter:Distribution, UtilityCost:Tariff)
  • If the name is a custom meter name, then it is left untouched.
  • If the name is a meter name with a sub-enduse, then it is processed with the special 9.4 section that screens for custom meter names and then call ReplaceFuelNameWithEndUseSubcategory for every field.
• Test defect file: DOE Prototype Medium Office
  ASHRAE901_OfficeMedium_STD2019_Denver.idf.txt
  • A few random custom meter names (Test:Electric, Test Electric Energy) and a normal meter name(Electric Equipment Electric Energy) were added to the objects below. It was confirmed that random custom meter names were not transitioned, and normal meter names were transitioned correctly in
    Meter:Custom
Meter:CustomDecrement
EnergyManagementSystem:Sensor
DemandManagerAssignmentList
ElectricLoadCenter:Tranasformer
ElectricLoadCenter:Distribution
UtilityCost:Tariff

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

[mitchute]

Looks fine to me. The test file transitioned successfully and runs with current develop. I'm not planning on running this new transition utility with the entire gamut of 9.3->9.4 transitions tests like we did right before release, but I suppose I could if it's absolutely necessary.

@mjwitte feel free to add comments and merge when ready.

[mjwitte]

@dareumnam Looking more closely at this, the real problem is here

                CurVar=4   ! In case Source Meter would change
                DO Var=4,CurArgs,2

The 4s should be 5s here. This DO loop will make the correct replacements from the list in Report Variables 9-3-0 to 9-4-0.csv

[mjwitte]

The special section for 9.4 is good up to here - this catches any changes needed for field A3 Source Meter Name (and avoids breaking the name if it came from a user-defined custom meter).

[dareumnam]

Thank you for the review. I'll update the code and push it again.

[hongyuanjia]

Sorry to chip in. But shouldn't the 4s be 3s here? The 3rd field is Source Meter Name and its value should also be updated according to Report Variables 9-3-0 to 9-4-0.csv?

                CurVar=4   ! In case Source Meter would change
                DO Var=4,CurArgs,2

[mjwitte]

@hongyuanjia No. Field 3 is handled in it's own block, lines 1224:1235.

[hongyuanjia]

@mjwitte, thanks for the clarification. So only the source meter name will be changed if necessary. Previously I was thinking this code block should replace fuel names for all possible meters, including those listed Output Variable or Meter Name X.

[mjwitte]

@hongyuanjia You may be right. I suppose a custom meter could reference other custom meters or a user-defined end-use meter. @dareumnam will build test files for more use-cases.

[mjwitte]

This DO loop is not needed.

[dareumnam]

Removed.

[mjwitte]

This subroutine is not needed.

[dareumnam]

Removed.

[mitchute]

Thanks @dareumnam for the quick fix, and thanks @mjwitte for the code review. I've tested it again and it looks good. Anything else to do here before this goes in?

[mjwitte]

@mitchute I think that's all for this object. Looks like we may need add the special 9.4 meter name piece to EnergyManagementSystem:Sensor, DemandManagerAssignmentList, and ElectricLoadCenter:Distribution, because these can all reference a meter name.
@dareumnam From your test file, it looks like normal meter names are transitioned correctly. But a custom meter name could get broken. Similar to #8297

[dareumnam]

This is ready for review.
In objects that accept report variable or meter name (Meter:Custom, Meter:CustomDecrement, EnergyManagementSystem:Sensor, DemandManagerAssignmentList, ElectricLoadCenter:Tranasformer, ElectricLoadCenter:Distribution, UtilityCost:Tariff)

• If the name is a custom meter name, then it is left untouched.
• If the name is a meter name with a sub-enduse, then it is processed with the special 9.4 section that screens for custom meter names and then call ReplaceFuelNameWithEndUseSubcategory for every field.
  Test defect file:
  ASHRAE901_OfficeMedium_STD2019_Denver.idf.txt

[mjwitte]

Tested with revised defect file. Looks good.