Solar resource profile per site | renewables.ninja API

[akorkovelos]

In the current version of the code the ghi_curve is loaded for a random location in the country (see zm-2-pv.csv within input data). Then, the daily solar availability is adjusted to the annual GHI extracted at each location/site from a GHI raster layer (WB Global solar atlas). The task here is to build a function that renders the hourly profile for the latest year available in renewables.ninja, using their API service. We want to test:

1. If/how this improves the accuracy of solar profile/curve
2. Impact on computational times for the sample 5000 sites

[julcan7]

Hi @akorkovelos I worked a bit on this task. I pulled a branch, I am not familiar yet how this works out, let me know if you can see my changes. I created a Jupiter notebook (API_Renewable_Ninja) to evaluate the performance of this task.

Methods:

• Based on the script ZEP Mini Grids a function was adapted to generate PV electricity production from different locations (30), assuming that there are not losses in the system and an installed capacity of 1kW.
• An API function was defined to retrieve PV electricity generation from same locations with a fixed installed capacity of 1kW, perfect conditions are also assumed.
• Hourly 2019 values were used to compute PV generation output from the two describe datasets. Statistics for the yielded annual energy is compared between the two datasets for 30 sites.

Limitations

• Retrieving information from renewable ninja website has the following limitations:
• Number of requests are constrained. As it is explained in the documentation, requests are limited to a limit of 50/hour.
• The input parameters are associated with the following variables: Latitude, Longitude, data from, data to, dataset, Capacity, system_loss, tracking, tilt, azim. The retrieve dataset contains the following outputs: Electricity, irradiance diffuse, irradiance direct and temperature.

Conclusions:

• In general, it was observed that yielded annual energy from the original script are higher than the retrieved information from the API.
• 1.48 minutes to retrieve and processed data from API for 30 locations.
• It would be possible to request access to retrieve data from more than 50 locations. A request is needed

May be if you have the chance we can discuss today on our meeting with the team on how to proceed and if there are other comparisons you would like to have. Please, let me know.

[akorkovelos]

Excellent work! A go-around to the request limitation is to create bigger sample areas (e.g., 5-10 km2) and associate sites to the nearest extraction point. There are two different approaches we can try:

1. Split the country into <50 bins, extract the data, and store it as input before the model is even run (pre-processing). We may add this as a prerequisite to the analysis. Then, for each site, we run a simple nearest neighbor and look-up the csv. radiation data to the closest location.
2. Run a spatial k-means clustering method on the sites we have (k<50), define the areas on a map (polygons), extract the data from renewablesninja and then run (1) in a similar manner.

Let's try both and again test the accuracy of the methods. Let's try to make this optional in the code: one may use the simple fast method with X% discrepancy or the more detailed method, which might require additional computational time/resources.

PS1. Please check if we can download multiyear data (see zm-2-pv.csv within input data) and apply multiyear average hourly curves. This will alleviate (hopefully) issues with random incidents.

PS2. You can also check how we could add some noise/randomness to the hourly data; to cover unpredicted events.

[julcan7]

Hi Alex,

Coming back to this thread, I wanted to update it, but somehow I forgot about it. Most of the analysis is described in this notebook. In summary, a function will recover GHI and temperature from the administrative region where the minigrid/point belongs to and assign them to it. The data was downloaded from MERRA-2.

Regarding PS1 and then PS2 above, for PS1, we could replicate the data extraction for each centroid for each year and come up with a summary for a period of time (10 years?), what do you think?. Regardint PS2, I understand the nature of the task, but if we want to reduce random incidents in PS1, why would we want to add some randomness with PS2? I would like to understand a bit better what we would like to assess when adding randomness to the data: battery performance?, diesel-generator usage?, sizing of installed capacity?, or some other parameter?

Thanks!