Title 24 updates for SWHC049

[simularis]

Pull Request (PR) Description

SWHC049 update triggered by new version of Title 24 codes.

• Updated code files for SWHC049.
• Additionally, added cohorts/case_names to enable running base case models for SWHC045 in the same folder.
• Updated measure subfolder name to proposed measure version pending submission in eTRM.

PR Owner

• Label the PR with at least one of the following: New Measure, Bug, or Feature.
  • New Measure
• Assign a reviewer.

PR Author

• Make sure the PR branch is up to date with main branch at the time of the PR submission
• Craft a succinct title that effectively encapsulates the essence of the pull request, providing a general overview of the proposed changes.
• Label the PR with at least one of the following: New Measure, Bug, or Feature.
  • New measure
• Provide a concise description of the measure, bug, or feature. Submit one PR per measure.
• N/A For a new measure, attach a workbook named DEER_EnergyPlus_Modelkit_Measure_list_working.xlsx, containing only rows used for post-processing the measure.
  • SWHC049 already defined in measure list
• Add comments in the code when necessary to facilitate the review process.
• Add a comment before the added code, including the author's full name, company, and specifying if it's a bug fix, new measure, or feature.
• For a new feature or bug, demonstrate the impact on energy consumption for selected cases with justification using plots and descriptions.
  • see eTRM
• For a new measure, add a summary table showing total energy consumption per simulated case.
  • see eTRM*

PR Reviewer

• Conduct a thorough code review.
• If the branch is behind the main, merge the branch locally to check for potential conflicts.
• If a bug, locally reproduce it and compare energy consumptions before and after.
• Explore creative ways to stress-test the code.
• Locally check the error file and other outputs.

[nfette]

We encountered some issues applying the conventional post-processing workflow to obtain impacts for 'Res' building type:

1. Some folders had partial 'results-summary.csv' file from a testing run for only one climate zone. Solution: we rebuilt results-summary.csv files.
2. Modelkit rake results crashed while preparing hourly result files. However, the crash occurred after 'results-summary.csv' output was saved. Some of the old residential prototypes have extra hourly data. Solution: we were able proceed in spite of the script crashing since the hourly result files are not used in the next step.
3. While running at least one of the DMo.py, SFm.py, and MFm.py scripts, we did not manually enter the correct measure_name, so the output file current_msr_mat had TechIDs not applicable to this measure. Solution: a long term fix would be to make a command-line oriented script that does not require manual editing (as in Residential data transformation script improvements #11). The immediate workaround was to edit the scripts to enter the measure_name consistent with measure list workbook and re-run the script. We saved a copy of each modified script within the model outputs archive documentation for convenience.
4. DMo.py, SFm.py, and MFm.py failed with an error when processing subfolders DMo, SFm_New, and MFm_New (every folder containing new vintage models). On inspection, we found that this was due to lacking models in the New vintage folder at the PreTechID efficiency level for AR offerings (SEER13). This points to broader problem that these scripts rely on the presence of models to establish permutations in the output file, and the scripts assume without verifying inputs that measure list entries follow some patterns that might be unstated (uniqueness constraints). Solution: we updated rows in the measure list workbook for New vintage to set PreTechID = blank, and label these rows with a new and distinct MeasureID.
5. Peak period demand values and demand savings seemed unusual. On inspection, we found that DMo.py, SFm.py, and MFm.py had relied on an assumption about structure of individual model hourly output files (instance-var.csv), namely that whole building electricity was the last column. However, this assumption was not guaranteed by models (see Output:Meter: invalid Key Name="GAS:FACILITY" #6) or verified by the script. Most of these models have extra hourly outputs, and the scripts seemed to be pulling whole building gas usage instead of electric usage. Solution: collect hourly output column based on name instead of position (as in Residential data transformation script improvements #11, Hourly data column selection not robust #12, and 0c124f3).
6. SFm.py script applied to SFm_New folder yielded output files labeled with BldgVint = 1975/1985 rather than New, as expected. This was a regression introduced by a6939a1. Solution: created a variable in the script to trigger different logic for new and existing vintage runs.
7. Re-importing data and running post-processing scripts takes a while to run manually, which slows the process of debugging and iterating. Solution: a long term fix is in progress at Dev deer ues tool #160. The workaround for this measure was to make a customized copy of the PSQL file already included in main branch, run_step5.psql.