Hourly rate table #684
Hourly rate table #684
Conversation
Introduces a new endpoint `/job/hourly_rate_table` that generates an Excel file with hourly rate data for one or more scenarios. Adds `hourly_rate_helpers.py` with utility functions for datetime generation and safe dictionary access, and implements the `hourly_rate_table` view to assemble and return the Excel file based on scenario data.
Enhanced the Excel export in hourly_rate_table by adding specific formats for datetime, integers, and energy rates. Rate headers now use the rate name from urdb_metadata for clarity. Data columns for load and peak load use integer formatting, and datetime strings are written as Excel datetimes for better compatibility.
Bill-Becker
left a comment
Bill-Becker
left a comment
There was a problem hiding this comment.
The summary of the comments are:
- Change the name of the endpoint and function and update all references to that.
- Make this more generalizable to specify the table configuration - in this case, we want the datetime, load profile, peak loads, demand rate, energy rate - so can we make that a specific "configuration" where we can make different table configs for different purposes/use-cases, like we do for the other table endpoint.
| Accepts multiple run_uuid values via GET request parameters. | ||
| Format: | ||
| - Column 1: DateTime (based on first run_uuid's year and time_steps_per_hour) |
There was a problem hiding this comment.
The format of the data depends on the custom table config, right?
There was a problem hiding this comment.
I see now that we don't really have a template where we can specify which timeseries data we want to include in the spreadsheet, like we do for the /get_results_table endpoint with the input custom_table_name parameter. Ideally we could generalize this endpoint so that we're not just creating a specific table that the ANCCR project wants, and instead it could be used to generate other tables with TBD configuration. Can you give that a try? Ideally we'd have a separate file where we specify that, like we have for custom_table_config.py, but I'd also be fine if we wanted to include that in the same "helper.py" file you created for this endpoint.
reoptjl/views.py
Outdated
| - Column 5: Demand Charge from first run_uuid ($/kW) | ||
| - Columns 6-7, 8-9, etc.: Energy and Demand charges for additional run_uuids | ||
| """ | ||
| from reoptjl.hourly_rate_helpers import ( |
There was a problem hiding this comment.
Update this function name too for consistency
There was a problem hiding this comment.
Changed to timeseries_table_helpers.py
| }) | ||
|
|
||
| # Set column widths | ||
| worksheet.set_column(0, 0, 18) # Hour column |
There was a problem hiding this comment.
Will this work with sub-hourly intervals?
There was a problem hiding this comment.
I tried to make it work with sub-hourly data but I think the results in the table will always have to be hourly since the URDB only has hourly data. I will have to fix the load data to be the average load over each hour for consistency.
Renamed hourly_rate_helpers.py to timeseries_table_helpers.py and updated all references accordingly. Added (but not currently used) custom_timeseries_table_config.py to define flexible timeseries table configurations. Refactored the hourly_rate_table view and URL to get_timeseries_table, enhanced Excel formatting with colored headers, and improved code organization for future extensibility.
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
Creates an excel table to show hourly date (timestep, load kW, peak monthly load, rate 1 (hourly or sub-hourly energy rates), rate 1 (hourly or sub-hourly demand rates), [If additional run_uuids are sent] rate 2 (hourly or sub-hourly energy rates), rate 2 (hourly or sub-hourly demand rates)
What is the current behavior?
Endpoint handles run_uuids to show the fields from above.
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change?
This shouldn't break anything since it's a new endpoint.
Other information: