In the publicly released raw ComStock results the timestamp year is 2012, but I believe this should be 2016 as indicated in ComStock/blob/main/resources/options_lookup.tsv.

Example:
Simulation state/upgrade=0/state=24/85422-0.parquet has a large difference in weekday/weekend schedule:

• Weekday Start Time: 4:45
• Weekday Duration: 17.45
• Weekend Start Time: 9:00
• Weekend Duration: 11:45

Using the provided 2012 timestamp, the operating schedule does not seem to match usage pattern:

Adding 4 years to the timestamp seems to yield more reasonable results:

Using the provided 2012 timestamp, the average consumption by day of week does not seem to match expected weekday/weekend pattern:

Adding 4 years to the timestamp seems to yield more reasonable results:

Raw ComStock results: https://s3.console.aws.amazon.com/s3/buckets/nrel-pds-building-stock?region=us-west-2&tab=objects

Add district energy emissions factors to the emissions_reporting measure

On the Building Characteristics tab, if I select a location before the histogram loads, then the histogram title will be "Currently Viewing: [Location Name]", but the data will be for the whole dataset. The "Update Search" button is grayed out, even if I change the building characteristic. I can use "Add Filters" to select the same location, but I suspect many people won't notice the mismatch.

(This applies to both ResStock and ComStock.)

Outdoor air fraction for PTAC/PTHP units is reported as 0, even though there is OA in the units. It looks like the comstock sensitivity reports measure only loops through air loops, so zone equipment with OA is not being captured.

https://github.com/NREL/comstock-internal/blob/develop/measures/comstock_sensitivity_reports/measure.rb#L608-L706

• CZs 7, 7A and 7B are all present in our sampling
• There are only options for CZ 7 in the options_lookup.tsv
• We need to decide how to handle this. Some options include: (1) Change climate zones 7A and 7B in buildstock.csv's to 7 after sampling; (2) Add duplicate entries in options_lookup.tsv for 7A and 7B; (3) Either remove CZ 7 or 7A/B from ComStock and keep the other.

Additional comments from @asparke2:
For the column climate_zone in buildstock.csv, the options_lookup.tsv maps the values 7, 7A, and 7B all to the measure input climate_zone=ASHRAE 169-2013-7A because openstudio-standards uses ASHRAE 169-2013-7A and ASHRAE 169-2013-7B as climate zones.

In the buildstock.csv file, the samples in:
02 AK use climate_zone=7
23 ME, 26 MI, 27 MN, 38 ND, and 55 WI use climate_zone=7A
08 CO and 56 WY use climate_zone=7B

These appear to come from the mappings defined in the file: spatial_tract_lookup_table_publish_v4.csv.

We could change all of the mappings in this file to use 7 instead of 7A and 7B, or could leave as-is. Either way, unless openstudio-standards is changed, will need to continue mapping everything to ASHRAE 169-2013-7A in options_lookup.tsv.

The ComStock timeseries outputs measure currently only creates a timeseries column for each fueltype/enduse combination found in the model. If you do a small run that has no models with a particular fueltype/enduse combination, then the buildstockbatch postprocessing won't know that that combination existed and the postprocessed timeseries won't have these columns. When combining one run with a different set of columns than another (for example, during and EUSS release), these missing columns have to be added into the individual timeseries files to avoid errors in postprocessing.

All outpatient buildings with interior equipment template > ComStock 2013 are failing with this error: [openstudio.model.ElectricEquipmentDefinition] Latent Fraction and Lost Fraction sum to 0.7 and you supplied a Radiant Fraction of 0.5 which would result in a sum greater than 1.0

I think I've tracked this down to the toilet space type, which for some reason has different radiant/latent/lost fractions than every other space type in outpatient buildings. When the building is first made, it gets the Pre-2013 values (frac latent = 0, frac radiant = 0.3, frac lost = 0.7). Then, when set_interior_equipment_template is run, it resets the values to the 2013 numbers (frac latent = 0, frac radiant = 0.5, frac lost = 0). I think it may be the order that the values are set causing the issue (i.e. it sets frac radiant = 0.5 before frac lost gets reset from 0.7 to 0, so it adds up to more than 1).

Two solutions here:

1. Investigate the order the fractions get set and possibly reorder. However, there could be other space types that would have the same issue if the order is changed. It would bea lot of work to go through every space type and figure this out.
2. Change the toilet space type fractions for post-2013 models to be the same as 2013. It seems weird that those fractions would change that drastically in 2013, and should have very little impact on the model anyways. This option seems a lot easier. It does look like "Janitor" and "Undeveloped" space types have the same values, but there is no electric equipment object in the model for Janitor space type, and Undeveloped space type is not used.

This change affects about 0.2% of the total stock, but 6% of outpatient buildings, which already have a high failure/timeout rate.

Currently, all RetailStripMall buildings (even those with no food service component) are being assigned to the B: Food-Service, Freestanding and in Strip Malls with Small Packaged Units.

1. Assign any RetailStripMall buildings with no restaurant component to the "
2. Rename the "B: Food-Service, Freestanding and in Strip Malls with Small Packaged Units" to "B: Buildings with Some Food-Service, Freestanding and in Strip Malls with Small Packaged Units"

So the resulting two segments would be:

SEG_A = 'A: Non Food-Service Buildings with Small Packaged Units'
SEG_B = 'B: Buildings with Some Food-Service, Freestanding and in Strip Malls with Small Packaged Units'

Currently, the ComStock class in comstockpostproc loads the metadata for all upgrades into a single Polars dataframe and then does operations such as creating new columns, etc. It also writes the resulting data to a single, large ComStock wide.csv file. While this is all convenient and perfectly fine for test runs or full runs with a few upgrades, it is running into memory limits of 32GB RAM machines for full EUSS runs.

Potential solutions:

1. Process and save each upgrade individually.
2. Use Polars lazy dataframe techniques to reduce memory consumption. Unclear how much this would be able to save.

Baseline economizer fault measure is causing baseline model failures, increasing baseline failures rate from 1% to >4%. An example severe error message from the error file is shown below:

** Severe ** Invalid Actuated Component Unique Name =ZONEWAREHOUSEFINEBSTORYGROUNDPSZACMAXOASCH
** ~~~ ** Entered in EnergyManagementSystem:Actuator=SCH_FRACTION_OA_MAX_1
** ~~~ ** Component Unique key name not found
** ~~~ ** Use Output:EnergyManagementSystem object to create .edd file for valid component names.
** Severe ** Invalid Actuated Component Control Type =SCHEDULE VALUE
** ~~~ ** Entered in EnergyManagementSystem:Actuator=SCH_FRACTION_OA_MAX_1
** ~~~ ** Control Type not found
** ~~~ ** Use Output:EnergyManagementSystem object to create .edd file for valid component control types.
** Fatal ** Errors found in processing Energy Management System input. Preceding condition causes termination.

Model files shown below:
eplusout.err.txt
in.epw.txt
in.osm.txt
run.log.txt

I would love an x-axis label for the histogram, especially since it says "Output: energy_consumption" above it.

This applies to both ResStock and ComStock.

EnergyPlus at some point replaced ReadVarsESO with a native CSV writer. Switch to this CSV writer and remove the ReadVarsESO executables currently being shipped with ComStock.

Currently, ComStock runs the simulations for design days. This adds additional timeseries outputs which must be removed during postprocessing. It also presumably takes additional computation time, although how much is unclear. Not sure if this change needs to happen in ComStock simulation settings or in openstudio-standards.

The loads component measure unit tests are currently broken, among others. See here

Current options for ASHRAE 'climate_zone' arguments in ChangeBuildingLocation measure specify ASHRAE 169-2013:

But when the measure sets the climate zone info in the model, it tries to remove the string 'ASHRAE 169-2006-' from the climate zone argument:

This results in the 'value' field of the OS:ClimateZones object populated with the whole climate zone string:

where it should just be the designation:
https://github.com/NREL/OpenStudio/blob/05c60768c1e1057083ce644d49711f7377f8ce1e/src/model/ClimateZones.hpp#L42-L44

I think the only implication of the value field containing the whole cz string is that any measure that uses the value has to strip out the extra characters, as in 'set nist infiltration coefficients':

But check if there's anything in postprocessing that might be affected by this.

Sometimes comstock-postproc creates negative numbers in enduse columns, which is probably caused by splitting fuel types or end uses. Who knows. Anyways, create a check for this to find goofy results early.

Update ComStock to OpenStudio 3.7.0 and associated openstudio-standards gem.

• Make an .aws directory in your home directory
  • Windows: C:\Users\myname\.aws
  • Mac: ~/.aws
• Download the ZIP file for NREL's aws-sso-tool into your .aws directory
• Activate a Conda environment that has boto3 installed in it for example, the comstockpostproc environment
• Connect to the NREL VPN
• Setup the AWS-SSO-tool following the directions in the README
  • Select the nrel-aws-resbldg-developers role

$ python aws-sso-tool config

• Get credentials which expire every 8 hrs, so you must connect to the NREL VPN and get-credentials every 8 hrs

$ python aws-sso-tool get-credentials

Currently, ComStock reports timeseries data in a variety of units (kWh for electricity, Therms for gas, kBtu for other fuels). This is then transformed into kWh during postprocessing, which takes additional compute time and adds another step with potential errors. Also, the column names in the timeseries data should be generated in the desired final format instead of having to change them in postprocessing using regex.

Currently, ComStock reports propane and fuel oil no 2. combined into the single "other fuel" in the annual results. They are already reported separately in the timeseries data. Report them out separately in the annual data. Change the reporting measure, then also change the postprocessing and SightGlassDataProcessing to match.

When space floor areas are too small relative to exposed perimeter (e.g. Outpatient buildings), the F-Factor construction resistance will end up negative causing EnergyPlus to fail.

F-factor constructions are set in openstudio-standards (and might need to be fixed there):

https://github.com/NREL/openstudio-standards/blob/d2b5e28928e712cb3f137ab5c1ad6d8889ca02b7/lib/openstudio-standards/prototypes/common/objects/Prototype.Model.rb#L620

It would be possible to replicate the EnergyPlus calculation:

https://github.com/NREL/EnergyPlus/blob/b1b40685e5ab32f56777510b5b499aa15ce75ebf/src/EnergyPlus/HeatBalanceManager.cc#L4836-L4844

when the constructions are created, and override the area or perimeter input force Rfic to be > 0.0.

Reopened from comstock-internal. This previous fix seems to not have been comprehensive.

The timeseries data currently includes water use and zone temperature. This is not necessary and adds extra overhead to the postprocessing and on-disk size to the results. Remove these columns.

Currently, ComStock (by way of openstudio-standards runs the simulation for sizing periods. Check the EnergyPlus documentation to confirm that this won't change sizing results. Also, it might be possible to reduce the simulation time further by changing this field to only run if/when necessary, which appears to be only when some types of plant loop sizing settings are used.

For some reason the e2e not works properly.

  4) analysis-page.spec.ts:53:7 › Office_HVAC › "Analysis" page › options › seed model is "SmallOffProto.osm"

    Test timeout of 30000ms exceeded while running "beforeEach" hook.

       at shared.spec.ts:57

      55 |     test.describe(CURRENT_PROJECT, () => {
      56 |       hook === Hook.each
    > 57 |         ? test.beforeEach(PROJECT_SETUP_DETAILS[CURRENT_PROJECT].beforeHook)
         |                ^
      58 |         : test.beforeAll(PROJECT_SETUP_DETAILS[CURRENT_PROJECT].beforeHook);
      59 |       tests(CURRENT_PROJECT as Projects);
      60 |     });

Need deep dive.

@JanghyunJK can you either remove these rows or add the necessary content to the reporting measure to output the fields? We shouldn't have TODOs in the column definitions .csv:

results.csv,build_existing_model.fault_hvac_economizer_damper_stuck_apply_measure,TODO,FALSE,FALSE,float,,,
results.csv,build_existing_model.fault_hvac_economizer_damper_stuck_damper_pos,TODO,FALSE,FALSE,float,,,
results.csv,build_existing_model.fault_hvac_economizer_damper_stuck_duration_days,TODO,FALSE,FALSE,float,,,
results.csv,build_existing_model.fault_hvac_economizer_damper_stuck_econ_choice,TODO,FALSE,FALSE,float,,,
results.csv,build_existing_model.fault_hvac_economizer_damper_stuck_start_day,TODO,FALSE,FALSE,float,,,
results.csv,build_existing_model.fault_hvac_economizer_damper_stuck_start_month,TODO,FALSE,FALSE,float,,,

Greater than 100% cooling savings observed in 6 models in full ComStock run for the HP-RTU measure. All models are either FullServiceRestaurant or Stripmall in 6A, 7A or 7B climate zones. This has been identified to be a baseline issue. In the eplusout.err file, several cooling coils receive the following warning:

** Warning ** CalcDoe2DXCoil: Coil:Cooling:DX:SingleSpeed="ZONE FULLSERVICERESTAURANT KITCHEN B END_A - STORY GROUND PSZ-AC 1SPD DX AC CLG COIL 90KBTU/HR 8.9EER":
** ~~~ ** Energy Input Ratio Modifier curve (function of temperature) output is negative (-8.601E-002).
** ~~~ ** Negative value occurs using a condenser inlet air temperature of -6.0 and an inlet air wet-bulb temperature of -8.9.
** ~~~ ** Resetting curve output to zero and continuing simulation.

Pulling and running the individual models in OS, the cooling coil electricity rate drops below zero periodically throughout the year, indicating that the performance curve output is not being set to 0 when it hits this warning, and instead remaining negative.

To confirm this is a baseline issue and not an issue with the upgrade measures, we looked at dining and kitchen air loops within the FullServiceRestaurant model. The HP-RTU measure is not applicable to kitchen air loops, so we would expect the baseline and upgrade models to have the same systems for kitchen air loops, and different systems for dining loops. This is confirmed when looking at the model .osm files. Furthermore, the eplusout.err file for the baseline model hits the EIR warning included above for both kitchen and dining air loops. When the HP-RTU upgrade measure is applied, the model only hits the warning for kitchen air loops. This confirms that this is a baseline issue.

See model and weather file here:
in_baseline.zip

After further review, this issue seems to be stemming from 3 (out of 21) zones in the upgrade model that received the HP-RTU, resulting in negative cooling consumption for the model. Below is an example of the cooling coil electricity rate for one of these zones.

A quick review of zone and outdoor air conditions does not show any abnormalities. This will need to be investigated further, and curve bounds will likely need to be applied.

Additional information about the 8 models with negative cooling energy consumption for debugging purposes:

Building types: Full-service Restaurant or Strip mall (contain restaurant space types)
Climate zones: Cold or Very cold climate zones
Number of stories: 2, 3

README links are linking to the old repo, not this one

Temperatures in comstock_sensitivity_reports are averaged over the whole model run. This works ok for some output variables, but is confusing or wrong for others that have intermittent operation.
These variables should either be calculated from timeseries output, or removed.

We have a template for measure tests. Here:
https://github.com/NREL/ComStock/tree/main/resources/tests/models

The models are from earlier versions of ComStock and should be updated to stay current with the workflow.

This issue is to update the models with a recent run, and edit the template as necessary to add further direction (README?).

Bug found in comstock_measure_comparison.py under comstockpostproc

Description

When the upgrade dir name exceeeds 20 char and triggers the truncating operation in:

Suggestion

Logic needs to be added to handle this scenario, so that the last space in truncated upgrade_dir_name would be removed to match the generated directory.

comstock_sensitivity_reports is treating all gas coils as furnaces (1 gas coil = 1 furnace). Gas coils may be supplemental coils for other kinds of HVAC systems.

The fix is to check whether the coil is the primary heating coil in a unitary system before logging.

creating a fresh conda environment and running pip install -e .[dev] in comstockpostproc results in this dependency conflict warning:

awscli 1.29.74 requires colorama<0.4.5,>=0.2.5, but you have colorama 0.4.6 which is incompatible.

switching to colorama 0.4.4 to resolve this warning produces a new warning:

buildstock-query 2022.10.8 requires colorama>=0.4.5, but you have colorama 0.4.4 which is incompatible.

The dependencies require a colorama <0.4.5 and >= 0.4.5, which is not possible.

Code currently looks for 'singularity_output.job'

That file was changed in this commit to be 'openstudio_ouput.log'

Issue

options_lookup.tsv has redundant lines that were added as a "solution" to the workflow being broken by editing the file in Excel...except that when you edit with Excel, the 15.0 gets turned back into a 15, making these lines identical and causing the issue to re-emerge.

weekend_duration	15.0	create_typical_building_from_model	wknd_op_hrs_duration=15.0
weekend_duration	15	create_typical_building_from_model	wknd_op_hrs_duration=15.0

Proposed Solution:

modify weekday_duration.tsv files to have 15 instead of 15.0 OR alternatively modify the mechanism that looks up options to be smarter about identifying doubles and matching either 15 or 15.0 to to the same row.

Instead of constructing an RVI/MVI and running ReadVarsESO in TimeseriesCSVExport, add an OutputControl:Files object with
OutputControl:Files, Yes, ! CSV

Add criteria pollutants (NOx, SO2, PM2.5, PM10, Mercury, etc.) to emissions_reporting measure

Currently, buildstockbatch removes all the building characteristics from all of the upgrade_XX.parquet files except for upgrade_00. This saves space on disk, but in comstockpostproc we join these characteristics back in anyway. Modify buildstockbatch to leave these characteristics alone.

Some measures can result in negative savings.

For example, adding predictive thermostats (bldg_id = 107309, upgrade = 55) or adding demand control ventilation (bldg_id = 317216, upgrade = 18).

Data source: https://registry.opendata.aws/nrel-pds-building-stock/

This code attempts to warn users if there is mismatch between buildstock.csv and options_lookup.tsv. The warnings it generates look like this:

[12:54:27.405020 WARN] Could not find options for a parameter called 'env_roof_insul_r_val' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405104 WARN] Could not find options for a parameter called 'env_wall_insul_r_val' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405128 WARN] Could not find options for a parameter called 'env_window' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405146 WARN] Could not find options for a parameter called 'env_window_film' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405162 WARN] Could not find options for a parameter called 'env_cool_roof' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405179 WARN] Could not find options for a parameter called 'env_wall_eifs_r_val' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405216 WARN] Could not find options for a parameter called 'env_window_electrochromic' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405274 WARN] Could not find options for a parameter called 'foodsvc_dcv_exh_hood' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405297 WARN] Could not find options for a parameter called 'hvac_boiler_afue' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405313 WARN] Could not find options for a parameter called 'hvac_chiller_efficiency' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405340 WARN] Could not find options for a parameter called 'hvac_dcv' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
[12:54:27.405363 WARN] Could not find options for a parameter called 'hvac_economizer' in options_lookup.tsv. This could be an error (or not, if it's regarding an upgrade.) Check the tsv for typos and make sure that the parameter names in options_lookup.tsv match those in buildstock.csv.
...

This approach is fine if all parameters in the options_lookup.tsv are expected to be used for every simulation. However, when upgrades are included, the current approach creates extraneous warnings which will likely mask actual warnings that the user would want to fix.

It's unclear to me what the exact solution should be, but perhaps we could assign all of the options for a building from a row in the buildstock.csv and then go back to ensure that at least all of the Parameters in that file have been used.

During EUSS, we have to break the buildstock.csv into multiple separate runs. When this happens, unless you are careful, blanks in the file are converted into NA or other unexpected changes in the partial buildstock.csv files. Avoid this by eliminating blanks in the buildstock.csv file, likely as part of the sampling code.

Heating energy profile in California has odd spikes/dips from 7-9am:

Prevalent in ~1% of models

[utilities.Plane] Cannot compute plane for points [[-3.048, -7.62, 0], [-3.048, -3.048, 0], [-3.048, -3.048, 0], [-3.048, -7.62, 0]]
[openstudio.model.PlanarSurface] Could not compute plane for vertices for 'Surface 73'.
[openstudio.model.Surface] Cannot compute default Surface properties.
[openstudio.model.PlanarSurface] Cannot create a surface with vertices [[-3.048, -7.62, 0], [-3.048, -3.048, 0], [-3.048, -3.048, 0], [-3.048, -7.62, 0]]
[openstudio.measure.OSRunner] Measure Failed with Error: /lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:886:in fromFloorPrint' /lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:886:in makeSpaceFromPolygon'
/lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:828:in block (2 levels) in makeSpacesFromPolygons' /lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:816:in each'
/lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:816:in block in makeSpacesFromPolygons' /lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:767:in each'
/lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:767:in each_with_index' /lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_geometry.rb:767:in makeSpacesFromPolygons'
/lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_model_generation.rb:1178:in create_bar' /lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_model_generation.rb:1714:in bar_hash_setup_run'
/lib/resources/measures/create_bar_from_building_type_ratios/resources/os_lib_model_generation.rb:2400:in `bar_from_building_type_ratios'

Currently, ComStock uses comstock_column_definitions.csv to convert the names of the output variables generated using runner.registerValue() calls into the final column definitions exported in the datasets. Change the runner.registerValue() calls to instead report out the desired names. In reality, a layer to remove the measure name from the value would still be required, but it would make the workflow a little more streamlined.

Having to maintain two identical copies of options_lookup.tsv isn't great, and possibly a remnant of a previous workflow.

Ensure this is indeed redundant (could be code in buildstockbatch that needs it), refactor and/or remove.

Currently, the ChangeBuildingLocation measure is adding design days that match this list:

ddy_list = [
  /Htg 99.6. Condns DB/, # Annual heating 99.6%
  /Htg 99. Condns DB/, # Annual heating 99%
  /Htg Wind 99. Condns WS=>MCDB/, # Annual heating wind
  /Clg 1. Condns DB=>MWB/, # Annual cooling 1%
  /Clg 2. Condns DP=>MDB/, # Annual cooling 2%
  /Clg .4. Condns WB=>MDB/, # Annual cooling
  /Clg .4. Condns DB=>MWB/, # Annual humidity (for cooling towers and evap coolers)
  /January .4. Condns DB=>MCWB/, # Monthly cooling DB=>MCWB (to handle solar-gain-driven cooling)
  /February .4. Condns DB=>MCWB/,
  /March .4. Condns DB=>MCWB/,
  /April .4. Condns DB=>MCWB/,
  /May .4. Condns DB=>MCWB/,
  /June .4. Condns DB=>MCWB/,
  /July .4. Condns DB=>MCWB/,
  /August .4. Condns DB=>MCWB/,
  /September .4. Condns DB=>MCWB/,
  /October .4. Condns DB=>MCWB/,
  /November .4. Condns DB=>MCWB/,
  /December .4. Condns DB=>MCWB/,
  /January .4. Condns WB=>MCDB/, # Monthly cooling WB=>MCDB (to handle solar-gain-driven cooling)
  /February .4. Condns WB=>MCDB/,
  /March .4. Condns WB=>MCDB/,
  /April .4. Condns WB=>MCDB/,
  /May .4. Condns WB=>MCDB/,
  /June .4. Condns WB=>MCDB/,
  /July .4. Condns WB=>MCDB/,
  /August .4. Condns WB=>MCDB/,
  /September .4. Condns WB=>MCDB/,
  /October .4. Condns WB=>MCDB/,
  /November .4. Condns WB=>MCDB/,
  /December .4. Condns WB=>MCDB/
]

This includes all monthly conditions, and unnecessary 1% and 2% conditions for annual heating and cooling.

Reduce to this list:

ddy_list = [
  /Htg 99.6. Condns DB/, # Annual heating 99.6%
  /Clg .4. Condns WB=>MDB/, # Annual humidity (for cooling towers and evap coolers)
  /Clg .4. Condns DB=>MWB/, # Annual cooling
  /August .4. Condns DB=>MCWB/,
  /September .4. Condns DB=>MCWB/,
  /October .4. Condns DB=>MCWB/
]

Should be easy.

Add some custom keyword in Jenkins, and next time will be easier to build and run and debug.

The ComStock documentation has several TODOs listed in sections 4.7 plug and process, 4.8 service water heating, 4.9 HVAC. See this example.

Most of the TODOs are for content that should be added to the documentation.

This issue is to assign each TODO to person and task in teams, with a deadline before the next release.

I previously ran example projects provided by the ResStock locally with BuildStock Batch. The website of BuildStock Batch also mentions that this tool can be used to run the ComStock project. Just curious about the possibility of providing example projects. Thanks in advance.

Edit create typical and create bar to use the newly added modules in openstudio-standards.

Currently, we use a mix of Pandas and Polars in comstock-postprocessing. Change this all over to Polars. It performs better, and having one library to manage changes in would be nice. The exception to this is converting to Pandas right before plotting, because Seaborn works natively with Pandas.