-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor/feat: decouple solar profile generation from Grid object, add individual calculation #247
Conversation
Since |
8990fc1
to
e6c4dc1
Compare
I've updated the function name and behavior in the two places you mentioned, plus the demo notebook. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable and safe to merge. I think it could be nice to have a demo notebook or some docs regarding the required inputs for the individual calculation (an issue or future PR or whatever is fine) since there is a bit of setup needed before being able to call it.
I'd also consider disabling the failing tests so we keep develop
branch in a passing state.
e6c4dc1
to
d9210e3
Compare
Pull Request doc
Purpose
This partially addresses #213 by decoupling the solar profile creation from the Grid object and associated network-specific mappings. The user can now pass to the existing blended-state-attributes function: a
Grid
object (for convenience), or a dataframe of solar plants and a mapping of interconnections to state abbreviations (for maximum decoupling). A few miscellaneous unrelated changes also decouple other modules from theusa_tamu
grid model.This also introduces a new solar profile generation function which uses the individual attributes of each solar plant, since we have this information available if we start from the raw EIA data. The pre-existing function has been renamed from
retrieve_data
toretrieve_data_blended
, and the new function is namedretrieve_data_individual
. I'm not married to any of these names, in case anyone else has better ideas.A few more helper functions have been added to the
prereise.gather.solardata.nsrdb.sam
module to serve the shared logic of these two functions.The underlying NREL data downloading module has been updated to include local caching of the downloaded NREL data files.
What the code is doing
Within nrel_api.py: we add an optional
cache_dir
input, which if it is provided acts as a location to check for pre-downloaded files, and store newly-downloaded files. There's a new helper function_build_filename
to translate queries to filenames, similar to the existing function to translate queries to URLs.Within sam.py:
generate_timestamps_without_leap_day
andcalculate_power
to support the two new solar profile calculation functions.retrieve_data
function has been renamed toretrieve_data_blended
and refactored to be more flexible with its inputs. If the user passes a Grid object, then all relevant information (including zone mappings) comes from this object. Otherwise, the user must pass asolar_plant
dataframe with enough columns to derive relationships between zone IDs and states/interconnects, and a mapping of interconnect names to state abbreviation sets (interconnect_to_state_abvs
). This mapping can't be reliably derived from thesolar_plant
dataframe, since there may be states without solar plants in the given dataframe, but these states should still be considered in interconnect averages when looking at the EIA data table.retrieve_data
has also been refactored to no longer need theto_reise
data reshaping step, by constructing a dictionary of arrays as we go, and converting these to a dataframe as the final step of the function.retrieve_data_individual
has been added, which expects extra data columns to be present insolar_plant
, and uses these extra data columns to produce more precise profiles for each plant, considering its specific tracking type, inverter loading ratio (ILR), and tilt angle (for fixed-tilt systems).Within all other files: miscellaneous updates to constants or docstrings, no changes to functionality.
Testing
Unit tests seem to be failing sporadically because of a 502 Bad Gateway when trying to map buses within
prereise.gather.demanddata.eia.map_ba
, which I didn't touch. Not sure what's going on there.Both functions have been tested manually on the new HIFLD grid, with both invocation methods of the blended profile generator.
Usage Example/Visuals
The second function needs to be able to associate extra information from EIA Form 860 Table 3.3 (see #242 (comment)), so uses the CSVs created by the latest HIFLD-grid-generating code in the
daniel/solar_pv_only_plus_index
branch (message me and I'll point you to the files for testing), plus the PowerSimData branch which enables the HIFLD grid (Breakthrough-Energy/PowerSimData#566). For clarity, all usage examples will use this same HIFLD grid model.Generating blended profiles using just a
Grid
object:Generating blended profiles using a dataframe and dictionary (athough both are derived from a Grid object in this example):
Generating individual profiles using additional information within EIA's Form 860 Table 3.3
Time estimate
1 hour or more.