Add billing and price formation for flat and time-of-use rates

[lanesmith1]

This PR introduces two main additions to the postprocessing code:

1. Allows billing information for consumers and DSOs at the aggregate level to be calculated for the flat and time-of-use rates. This not only includes calculating the billing information, but also discovering the prices used to calculate the billing information per cost-of-service regulation principles.
2. Updates the case postprocessing script (run_case_postprocessing.py) to collect necessary information for the time-of-use and subscription rates. Namely, this allows period-specific metrics to be collected (e.g., off-peak-period and peak-period energy consumption) and enables the creation of demand and baseline demand profiles, both of which are necessary for the calculation of bills under the subscription rate.

To enable these changes, the following files are changed as follows:

• dso_rate_making.py updates read_meters to allow period-specific metrics under the time-of-use rate to be calculated, includes functionality to calculate hourly demand and baseline demand profiles for each meter (create_demand_profiles_for_each_meter and create_baseline_demand_profiles_for_each_meter, respectively), calculates billing information for consumers in the flat and time-of-use rate scenarios (calculate_consumer_bills), and determines the tariff prices needed to recover DSO expenses using a closed-form solution (calculate_tariff_prices). DSO_rate_making is preserved in a way that allows the rate information for each rate scenario to be determined or allows rate information for the original DSO+T implementation to be determined.
• dso_cfs.py updates the calculation of the DSO CFS to return capital and operating expenses that can be attributed to each month, which is needed to determine the expense-recovering prices in the time-of-use and subscription rates.
• Wh_Energy_Purchases.py allows the monthly energy purchases from the wholesale market to be accessed, which is needed in dso_CFS.
• dso_helper_functions.py allows the rate scenario under investigation to be specified
• run_annual_postprocessing.py allows the rate scenario under investigation to be specified.
• run_case_postprocessing.py allows the rate scenario under investigation to be specified and allows demand and baseline demand profiles to be calculated and saved depending on the rate scenario.

All feedback is welcome, though I would especially appreciate feedback on some things in run_case_postprocessing.py in particular. Since this runs on the cluster, I am less familiar with the directory structure. What is the best way for the people who are running this script to include information on the rate scenario and the time-of-use parameters?

• I currently have the rate scenario being specified through a hard-coded parameter in the case postprocessing script. Is there a better way to do this? Is there a metadata-like file in which this information might already be specified?
• I have the time-of-use rate parameters stored in a .json file and structured in a way that includes the parameters for each month in each DSO. This allows the time-of-use rate parameters file to be stored in each scenario's root directory (i.e., where the folders for each month's run and other summary files are located) when performing the regular postprocessing. However, I'm not sure how this is structured for case postprocessing. Since the case postprocessing script appears to define file paths differently from the other postprocessing scripts, I ended up making it so that the time-of-use parameters file needs to be included in the directory for each month's run. This seems inefficient though, especially because this file would need to be uploaded to each month prior to running the case postprocessing script. Is there a better place that I should indicate that this file will be stored?

[lanesmith1]

Following a discussion with @jk1066, the recent commit makes changes to run_case_postprocessing.py and dso_rate_making.py that should allow relevant rate scenario information to be pulled from existing files (e.g., the generate_case_config.json file). The changes also make use of existing relative paths for storing and accessing time-of-use parameters (i.e., the time_of_use_parameters.json file will be stored in the examples/analysis.dsot/data directory), as needed.

[lanesmith1]

@d3j331 I added the change we just talked about. This should be good on my end now