Enabling Multi-year in Resource Models

To get multiple years of resource data, some small changes can be done to the resource base-classes and the resource models. First, theres a few different cases to discuss/consider with the broader team (this is mostly focused on the API- resource models).

Requested Thoughts & Feedback from Users and Developers

Which of these should be enabled:

• resource_year provided as a list of resource years (potentially unordered) to get multiple years of resource data. For example: resource_year: [2007, 2008, 2009, 2007]. This would be nice in situations where someone is running a simulation with more timesteps than what's available in the desired resource model (like, running a 10-year simulation but wind toolkit only has 7 years of data).
  • If this should be possible, should they be able to provide filenames for the resource years? Should the filename list have to be the same length and have the same year-order as resource_year? Should resource_filename or resource_year take precedent? If a resource filename doesn't exist for a given year, should that be downloaded as-normal or should an error be raised?
  • If multiple resource filenames are provided and only 1 resource year, should we try to get the resource_year from that filename so we can check if it's valid or not? For example, GOESConusSolarAPI has valid resource years from 2018 - 2020, and GOESAggregated has resource years from 1998 to 20204. If someone provides a filename list of existing files that contains resource files from the GOESConusSolarAPI from 2018 - 2020 then GOESAggregatedSolarAPI from 2020-2024, these could be run with either model (since the files were already downloaded and the filenames were specified). In this case, if we check the resource-year from the filenames to see if they're valid for that model, it will fail (because the valid resource year only matters if you're downloading data).
  • If multiple filenames are provided, should the lat/lon of each be checked? Should we ensure that all the filenames are in UTC or local time?
• Should resource_year flag to use that year as the starting year and use all the following years needed to achieve the simulation length?
• Should resource_year be made as an input to the resource models (similar to lat/lon). If so, should this be integer meaning the first-year to use? Or should an array be allowed (similar to the list-thing in the first bullet point). Should resource_year only be made as an input if some new flag is set to True? If resource_year is an openmdao input, we likely shouldn't allow the user to specify the resource_filename or provide raw resource data.

General proposed approach

Other changes to enable multiple-years that don't depend on answers to the above questions:

• To align with Issue #870, the create_url() and create_filename() methods of each resource model should be updated to have an input of resource_year (removing the use of self.config.resource_year)
• The load_data() in the openmeteo resource models needs to be updated to not use self.config.resource_year. This can be done by removing 2 lines of code (where self.config.resource_year is used and the line that uses process_leap_day). This logic can be done in the resource baseclass after the data is loaded
• Add include_leap_day to the resource API config base-class (have it default to False), update create_url() in the NLR API models to use this option.
• Create a new function that starts as a copy of get_data() (like get_data_per_year()) that has inputs of latitude, longitude, resource_year, and first_call (maybe resource_filename depending on the answers to the above question). This can basically remain as-is, just delete the logic of if not site_changed and if not first_call (this should remain in the get_data() method. Also, before resource data is returned, the data should be clipped to only include the resource year input (this is because of the earlier mentioned changes to the open-meteo models, but special handling will be needed for the TMY solar resource models). The add_resource_start_end_times could also be removed from get_data_per_year().
• Revise get_data() to loop through resource years, making calls to get_data_per_year(). After each call to get_data_per_year(), append the timeseries data (will require separating out the timeseries data and the meta-data, this can be easily functionalized).
• After all the years have been looped through, then 1) run call to process_leap_day and 2) clip timeseries data to n_timesteps and 3) call add_resource_start_end_times().
  • this will require some changes to process_leap_day(). I propose splitting out the "checks" in proces_leap_day to a separate function.
• I also think that we should have a method that can return all the resource_years following the "starting" resource year if we want. This should check that theres enough future resource years to achieve the simulation length (this is only needed if we want resource_year to ever mean the 'starting' resource year). This would need to have special handling for leap-years and also for TMY datasets. The output of this method or function can be used to provide the years to loop through in get_data().

For the HPC resource models, these should be updated to use MultiYearWindX and MultiYearSolarX methods available in ReX but should be tested on the HPC prior to being merged into H2I.

Other considerations

Changes to the pysam solar model will be needed and probably changes to the pysam wind model and the floris wind model. The ac_annual() output of the pysam solar model does not exist if you run pysam as-is for more than 1 year. There are other things to consider here. One option is to loop-through the resource data years and simulating the pysam solar model once per year. If the other outputs of the pysam solar model are OK if multiple years are run, then we just need to update the output calculations to not use ac_annual and to update the capacity-factor calc to be per-year. With both of these options, we would need to know how to handle a case where someone wants to use the "lifetime" outputs and consider how that and the dc_degradation may be most appropriately handled. I've started playing around with this and I do think a larger discussion should be had (for example, dc_degradation is defined as the total degradation that year, not the added degradation in that year, which is weird to me. Should we add some user-friendliness to this in the pysam solar model?)

Changes to the pysam wind model are much easier than the pysam solar model, same with floris. We just may not be able to use any annual outputs from the PySAM wind model and instead have to calculate them as we do in FLORIS (but changing the annual electricity production and capacity factor calculation to accommodate for multiple years, and maybe this logic could eventually get moved to the performance model baseclass so it can be easily used by other models).

Start with the resource base classes and the mentioned create_url(), create_filename(), load_data(), get_data(), process_leap_day(), and add_resource_start_end_times() methods; review Issue #870 and the API resource models first. The work is not yet ready for implementation: done requires agreement on multi-year inputs, filenames, leap years, TMY data, and the required updates to HPC, PySAM, and FLORIS models.