QA methods for plane-of-array irradiance

[cwhanse]

This paper describes a workflow to establish quality of measured plane-of-array irradiance. The components and the workflow would be of significant value in this library.

[abhisheksparikh]

Hey @cwhanse,

I was wondering if I could get started on this one.

Is there a particular component you would like to prioritize? Section 6.1 Range limits seems to be interesting. I could not understand how the authors arrived at the upper limit for GTI though.

Best, Abhi

[cwhanse]

Hi @abhisheksparikh yes, please do! It will be a big job to put all of that paper's QC algorithm into code so best to break it up as multiple pull requests. I'd say start with the range limit checks. There's a check for GTI and another for GHI, which gives pvanalytics a second option (with the QCRad code already in place). Putting a second set of range checks will let us adjust the design of pvanalytics.quality.irradiance.

[cwhanse]

We can implement the method as published, except when it's clear there's a mistake in the paper, or where we need to close a gap the authors don't describe (such as handling edge cases like zenith=90). My guess, that upper bound on GTI is just a curve that roughly follows the upper edge of a scatterplot the authors made of their data.

[abhisheksparikh]

We can implement the method as published, except when it's clear there's a mistake in the paper, or where we need to close a gap the authors don't describe (such as handling edge cases like zenith=90). My guess, that upper bound on GTI is just a curve that roughly follows the upper edge of a scatterplot the authors made of their data.

Thanks, Cliff! For cases where the zenith > 75, do you have any recommendations for the lower limit of GHI and GTI? The paper says 0, which I don't think is very realistic. I went to this reference used by the paper - Project ENDORSE, and it mentions about the lower limit as $0.03 \times GHI_{toa}$ (GHI top of atmosphere) on page 23 and 28. Should we just ignore the discontinuity of lower limit at zenith > 75 and keep it at $0.01 \times I_{0} \times cos(SZA)$?

side question: Is $GHI_{toa}$ just $I_0 \times cos(SZA)$ (Because there is no diffuse in space, I guess)?

[cwhanse]

I would say implement as published (with the discontinuity) and use the first author's name (Lorenz) to identify the method. The ENDORSE method is slightly different, and could be implemented separately if there's interest. We could write Elke to ask if there's a name for this method that she would prefer.

I missed the QF=2 and QF=3 distinction when I looked at the paper. pvanalytics has a pattern to return a Series of boolean: True if the test passes, False if it fails. In this case, False means any of QF 1, 2 or 3. We can return an additional Series that gives the QF value at each point.

I think your description of $GHI_{toa}$ is correct.

[abhisheksparikh]

For testing the upper_limit, I generated a 5-min sample dataset in SAM. There are a couple of observations:

1. Since aoi is kept at 0 by SAM at night time, the upper limit comes out to be 1530.3, which is unrealistic.
2. There are cases when the aoi comes out to be greater than 90. This results in the upper limit as nan.

The following image is a sample day, showing the above two observations.

From the above observations, I was thinking that while calculating upper_limit, we should check the solar zenith, and if that is above 90, I should clip/change the aoi to 90. This will result in the upper_limit of 300.

Does this make sense?

[cwhanse]

Hi @abhisheksparikh sorry for this delayed response. For this function, I think it is safe to clip $AOI \le 90$ for the upper limit. Effectively, the upper limit of direct irradiance is $0.9 I_o cos(AOI)^{1.2}$ and the upper limit of diffuse is 300 W/m2, which seems low to me but that's what the authors published.

I think that night times (solar_zenith > 90) should return False if we describe the function as labeling values that pass the GTI limit check. I don't think either low or high limits are meaningful for night times.

[abhisheksparikh]

Hi @cwhanse - Thank you very much for providing guidance on this. I have created a draft PR implementing the function to check the poa_global (gti). I would like to implement other components as well once I get this one alright.

Please excuse me for the PR being a draft one. I still haven't got all the PR requisites checked (mainly editing the .rst files is giving me hard time). I am currently unable to generate previews of .rst files in VScode (I keep on getting errors while generating the preview)

Do you have any recommendations on how to edit .rst files efficiently?

Abhi

[abhisheksparikh]

Also, I used a python notebook while writing those functions. The notebook has some plots which could be useful. What is the best way to share this notebook? Put it in the docs\examples?

[cwhanse]

Hello @abhisheksparikh a quick read of the code looks good, thank you! I'll do a detailed review when you switch it to Ready. I edit .rst files in a text editor. I don't use VScode so probably can't help with the errors. The doc pages are built from the PR with a Github action so after we run the CI you can see the pages and make adjustments.

If you can convert the notebook to .py, we can add that to docs\examples in the appropriate folder.

[wholmgren]

@abhisheksparikh sphinx compiles the .rst documentation into html. I'm not aware of a vscode plugin that can do that on the fly. pip install pvanalytics[doc] should give you what you need to compile the documentation locally. Then cd to docs/ and run make html