CalTRACK Compliance

Checklist for caltrack compliance:

Section 2.2: Data Constraints

Section 2.2.1: Missing Values/Data Sufficiency

  • eemeter.get_baseline_data must set max_days=365.
  • eemeter.caltrack_sufficiency_criteria must set min_fraction_daily_coverage=0.9
  • (Data Preparation) Missing values in input data have been represented as float('nan'), np.nan, or anything recognized as null by the method pandas.isnull.
  • (Data Preparation) Values of 0 in electricity data have been converted to np.nan.

Section 2.2.2: Daily Data Sufficiency

Section 2.2.3: Billing Data Sufficiency

  • (Data Preparation) Estimated reads in input data have been combined with subsequent reads up to a 70 day limit. Estimated reads count as missing values when evaluating the sufficiency criteria defined in
  • eemeter.create_caltrack_billing_design_matrix must set percent_hourly_coverage_per_billing_period=0.9 for eemeter.compute_temperature_features and :any:`eemeter.caltrack_sufficiency_criteria must set min_fraction_daily_coverage=0.9.
  • (Data Preparation) Input meter data that represents billing periods less than 25 days long has been converted to np.nan.
  • (Data Preparation) Input meter data that represents billing periods greater than 35 days long for pseudo-monthly billing period calculations and 70 days long for bi-monthly billing period calculations has been converted to np.nan.

Section 2.2.X: Other Data Sufficiency Requirements

  • 2.2.4: eemeter.caltrack_sufficiency_criteria set requested_start_date and requested_end_date to receive critical warnings related to data outside of the requested period of analysis.
  • 2.2.5: (Data Preparation) Projects have been removed if the status of net metering has changed during the baseline or reporting periods.
  • 2.2.6: (Data Preparation) Projects have been removed if EV charging has been installed during the baseline or reporting periods.

Section 2.3: Data Quality

Section 2.3.1: Impossible Dates

  • (Data Preparation) For billing analysis, input meter data containing invalid dates for a valid month have been converted to the first date of that month.
  • (Data Preparation) Input meter data containing invalid months/years for have been removed and a warning has been generated.

Section 2.3.2: Duplicate Records

  • (Data Preparation) Meter usage and temperature data has used matching time zone information to ensure that the upsampled values represent the same periods of time.
  • (Data Preparation) If duplicate rows are found for meter data, then the project must be flagged as it may have sub-metering/multiple meters.

Section 2.3.X: Other Data Quality Requirements

  • 2.3.3: :any: eemeter.merge_temperature_data meter_data and temperature_data must be timezone-aware and have matching timezones.
  • 2.3.4: If NOAA weather data was used (which is roughly hourly), it has been normalized to hourly using eeweather.ISDStation.fetch_isd_hourly_temp_data.
  • 2.3.5: Warnings are generated in eemeter.caltrack_sufficiency_criteria if negative meter values are discovered as they indicate the possible presence of unreported net metering.
  • 2.3.6: (Data Preparation) Must generate warning for values that are more than three interquartile ranges larger than the median usage.
  • 2.3.7: (Audit) Resulting dataset of meter runs has been compared with expected counts of sites, meters, and projects.
  • 2.3.8: (Data Preparation) Meter data has been downsampled according to the desired frequency for analysis using eemeter.as_freq before merging of temperature data or modeling.

Section 2.4: Matching Sites to Weather Stations

Section 3.2: Balance Points

Section 3.3: Design Matrix (for Daily and Billing Methods)

Section 3.4: Fit Candidate Models

Section 3.5: Computing Derived Quantities