Skip to content
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

QA methods for plane-of-array irradiance #123

Open
cwhanse opened this issue Jan 11, 2022 · 11 comments · May be fixed by #167
Open

QA methods for plane-of-array irradiance #123

cwhanse opened this issue Jan 11, 2022 · 11 comments · May be fixed by #167
Labels
enhancement New feature or request
Milestone

Comments

@cwhanse
Copy link
Member

cwhanse commented Jan 11, 2022

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
Copy link

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.
image

Best,
Abhi

@cwhanse
Copy link
Member Author

cwhanse commented Oct 11, 2022

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
Copy link
Member Author

cwhanse commented Oct 11, 2022

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
Copy link

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
Copy link
Member Author

cwhanse commented Oct 12, 2022

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
Copy link

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.

image

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
Copy link
Member Author

cwhanse commented Oct 24, 2022

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 abhisheksparikh linked a pull request Nov 13, 2022 that will close this issue
8 tasks
@abhisheksparikh
Copy link

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)
image

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

Abhi

@abhisheksparikh
Copy link

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
Copy link
Member Author

cwhanse commented Nov 14, 2022

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
Copy link
Member

@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

@kandersolar kandersolar added this to the v0.1.3 milestone Nov 28, 2022
@kandersolar kandersolar added the enhancement New feature or request label Nov 28, 2022
@kandersolar kandersolar modified the milestones: v0.1.3, v0.1.4 Dec 16, 2022
@kandersolar kandersolar modified the milestones: v0.2.0, v0.2.1 Feb 14, 2024
@kandersolar kandersolar modified the milestones: v0.2.1, v0.2.2 Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants