-
Notifications
You must be signed in to change notification settings - Fork 32
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
Offset calculation and correction for irradiance data #170
Comments
The equation to compute the offset corrected irradiance looks good to me. irradiance_series_offset_corrected = irradiance_series - nighttime_offsets The effect of subtracting negative number will increase the adjusted irradiance by a Watt. |
The reference mentions that the thermal offset at night can be different from the daytime offset, depending on sky condition. This other paper I found goes so far as to say that the difference is large enough to make the nighttime offset unsuitable for correcting daytime data. Is the idea here that using the nighttime offset as a partial correction to daytime data is better than nothing? A couple comments about the code:
|
This is also the question in my mind. I have no objection in principle to adding this function, but the documentation needs to inform the user when it is appropriate to apply the nighttime adjustment. |
@kperrynrel When you made the adjustment to the midnight value, how will this handle the data if it is not in one minute intervals. For example, how will second level data be handled with the adjustment you have in place? I suspect that it will change the entire minute of data in this case. |
@kanderso-nrel Yes that is the thinking here. That a partial correction is better than nothing. You are correct the timestamps are assumed to be in local time. |
@PetersonUOregon I reran the above logic with 1-second resampled data and you are correct. The entire midnight minute is included in the previous day when calculating the average offset: |
This business of aligning data to the timestamp (it appears that @PetersonUOregon prefers left-labeled intervals, others prefer right-labeled) suggests that maybe the implementation could be done using |
I agree different users may have different preferences as to how they timestamp their data. I prefer timestamps that occur at the end of the time interval. My understanding is this would be right-labeled. I think the resample function you mentioned could work. All the data would be timestamped at the start of the interval (instead of the end). In doing this, the time stamps would all be shifted one time interval to the left. For one minute data this would look like: In doing this the left labeled time stamps for a day would all be correctly selected. I suggest that a user input be added to the function that gets how the data is labeled. Then the function would convert the right and center labeled data sets to left labeled and the function would then proceed as we have it. |
Just as a comment, Pandas use the term "closed" for the bin edge (e.g., in the resample function).
Calling the parameter In general, I think this would be a great function, even if it is not always the right choice to apply it! On another note, would it be an option to do the nighttime grouping based on the solar zenith angle instead of the time index (I think this would solve a lot of issues in regards to time-zone localization)? Update: I create a gist demonstrating how nighttime offset could be determined based on the zenith angle instead of the time. |
I came upon another recently published study that uses a very similar method:
In general, I think it is rather common to calculate a nighttime offset, and certainly would be worth having available. It might be a good idea to have the function return the corrected irradiance and not the nighttime offset. This way we avoid users getting the sign wrong (i.e., is the offset negative and should be subtracted, or is it positive and should be added). |
Thanks for posting this @AdamRJensen--the method you describe is almost identical to @PetersonUOregon's method, so it's encouraging that multiple people are approaching the problem similarly. I do like your idea of grouping on zenith angles instead of datetimes, I'll have to dig into that gist and see if I can adapt some of it in (perhaps adding a passed parameter for grouping?). I do have a function for calculating the corrected irradiance (correct_offset()), but perhaps I should make the naming more explicit here. |
@kperrynrel I'll happily draft up a PR if that would be of help? (I have pasted my code below, which all is contained in one neat function - I see that you have three different ones). The following code snippet should be able to do both the zenith and time based method:
|
@AdamRJensen I'm happy to go the route you're suggesting here as it simplifies the code considerably. Since I'm just directly adapting @PetersonUOregon's logic here though, I want to be respectful of his input. To better inform our decision, I did run some calculations on how Josh's function compares to Adam's, to see if changing the logic has a large effect on the overall correction. Here are the results: Overall, the differences are fairly minimal. I do want to point out that Adam's currently doesn't do the daytime correction, but Josh's does. Maybe we'd want to include a parameter called correct_daytime or something (for either function) to correct daytime values if desired, even though there may be issues with the daytime offset as mentioned above (but, as Josh mentioned, a partial correction may be better than nothing). |
If the two methods (@PetersonUOregon and in the reference @AdamRJensen found) give very similar results, they could both be included in the documentation. |
@kperrynrel In regards to your comment
I think there may be some confusion - the purpose of my function is to do exactly the same as Josh/yours - the only difference being how midnight is determined. Both functions correct the entire day by adding the nighttime offset. The PR that I have opened proposes one function that is capable of both Josh's method with midnight as 00:00 and my method (midnight when the zenith angle is at its max). I've attempted to add a parameter called |
@AdamRJensen apologies--I just noticed when I ran your function on the HEO data that daytime values weren't filling in and thought it was intentional: |
@kperrynrel That is simply due to poor coding on my part :) I have updated the PR and the example above. Please do share the data though. |
When I test my updated function with the code written by @kperrynrel above, then I get exactly the same results. This of course requires that the same |
Hey all, Josh Peterson has a method for calculating nighttime offsets in irradiance data and using these offsets to correct irradiance data. He has published on it here: This code is adapted from the following publication: http://solardat.uoregon.edu/download/Papers/Structure_of_a_comprehensive_solar_radiation_dataset_ASES_2017_Final.pdf
He requested adding this functionality to the package. I went ahead and adapted the code he sent over, which is as follows (it's still rough and needs work):
Essentially, the above set of functions calculates the daily nighttime offset for irradiance data (can be median or mean, settable), and subtracts the offset from the irradiance data to correct it.
How do we feel about adding it to the irradiance module? @PetersonUOregon let me know if I missed anything here; I did take a stab at the actual offset correction in the correct_offset() function.
The text was updated successfully, but these errors were encountered: