Decouple profile creation from PowerSimData Grid object

[danielolsen]

🚀

• Is your feature request essential for your project?

Describe the workflow you want to enable

I wish I could generate hydro/solar/wind profiles using an arbitrary collection of lat/lons (and maybe power levels for hydro), without requiring a Grid object and all of the other information it contains/requires.

Describe your proposed implementation

Anything that currently takes a Grid object will only take the relevant information directly, rather than looking into the Grid object to obtain this information.

[BainanXia]

Thinking about it carefully, I found this could be tricky. For the profiles that are generated using weather data + location, this can be easily decoupled. However, for profiles generated using other information, it could be tough. For example, generating hydro profiles, we reply on net demand, generating demand profiles, we reply on Pd, etc.

[danielolsen]

Could we de-couple in stages? It seems like the wind and solar profiles would be fairly straightforward at least.

[danielolsen]

Even for wind and solar, the current wind and solar profile generation scripts use some imports from powersimdata.network.usa_tamu.constants (e.g. to do aggregation of individual plant attributes to state sums, or to look up the appropriate state average for a given plant's state). This presents problems for generating HIFLD profiles which have different zone IDs and other elements within the model immutables. I think we'll want to refactor these scripts so that they look only at the dataframe(s) that are passed directly to the functions, and don't assume that all queries relate to any particular grid model.

EDIT: branch-in-progress is the daniel/decouple_profiles_from_grid branch.

[rouille]

Even for wind and solar, the current wind and solar profile generation scripts use some imports from powersimdata.network.usa_tamu.constants (e.g. to do aggregation of individual plant attributes to state sums, or to look up the appropriate state average for a given plant's state). This presents problems for generating HIFLD profiles which have different zone IDs and other elements within the model immutables. I think we'll want to refactor these scripts so that they look only at the dataframe(s) that are passed directly to the functions, and don't assume that all queries relate to any particular grid model.

EDIT: branch-in-progress is the daniel/decouple_profiles_from_grid branch.

It would be nice if we could find a way to throw an error if the meteorological data don't cover the passed plant data frame. The NSRDB and NOAA database won't work with the European grid and we want to let the user know that he cannot use this script for plants loacted in Europe. We can work with a lon/lat bounding box defined in a const.py in prereise/gather

[danielolsen]

It could be useful to have a set of constants related to regions, rather than grids. E.g. there's some USA-specific information right now (bounding box, state abbreviations) that's contained within the usa_tamu grid constants data that could be associated with the USA region, which then gets applied to both the usa_tamu and hifld (usa_hifld?) grid models.

[rouille]

It could be useful to have a set of constants related to regions, rather than grids. E.g. there's some USA-specific information right now (bounding box, state abbreviations) that's contained within the usa_tamu grid constants data that could be associated with the USA region, which then gets applied to both the usa_tamu and hifld (usa_hifld?) grid models.

Yes, there are a lot of constants we can factor out in the zones and plants module

[BainanXia]

Thinking a little more on this, maybe we could have PreREISE generate all regional profiles with some meta data tag, such as Asia, Europe, North America, etc. then leave "distribution" tasks for PowerSimData based on the parameters of a grid object that user specifies. In this way, we can conduct a clean decoupling between PreREISE and PowerSimData on profile generation. Also, the regional profiles could be the state-of-art public accessible datasets that one could find for the time being, i.e. in PowerSimData, we could either distribute or aggregate the "best" profile from PreREISE based on the granularity of the grid, for example, in a PCM, the grid granularity could be higher than the given profile, then we will need to distribute a regional profile down to nodes, whereas in a CEM, the grid granularity could be lower than the given profile, then we will do aggregation instead.

[danielolsen]

I believe this will be satisfied upon completion of #256, #260, and #261. EDIT: these are merged, so I'll close this issue.