I'm not convinced that daily maxima are particularly useful for solar radiation. At least where I live, fairly high spikes on otherwise cloudy days are common, and days with light to moderate cloud cover with significantly lower maxima are also fairly common. Simple averages are, at least, somewhat meaningful, and I don't think showing the daily maxima adds anything to them. Only counting as maxima values that are sustained for more than a specified time might make them more so.
On Tuesday, March 21, 2023 at 1:16:48 AM UTC-4 [email protected] wrote: > For myself, I found that for a yearly chart, using a bar chart with the > daily averages, and a crosshair to display the daily maximum, a > comprehensive way to display solar readings. > > Peter Fletcher schrieb am Donnerstag, 16. März 2023 um 00:29:26 UTC+1: > >> In order to look at different ways of presenting solar and UV radiation >> data, I dumped the contents of weewx.sdb to a csv file and used Excel to >> manipulate and chart the relevant data. The attached charts show daily >> averages for solar and UV radiation for four-month summer and winter >> periods in 2021 and 2021/22. More (probably 'simple') averaging would >> probably be done in producing yearly charts for a website, but I thought it >> helpful to get a somewhat more granular picture of the processed data. For >> all the charts and both types of data, 'Avg ...' uses the current >> calculation (simple averaging of all readings for the 24 hr day), 'NZ Avg >> ...' represents the average of all non-zero readings acquired during the >> 24hr day, and 'Day Avg ...' represents the average of all readings >> (including any zeroes) recorded between sunrise and sunset (calculated for >> my location and the date by the standard NOAA method). >> >> For solar radiation, in both seasons, the non-zero and daytime averaging >> methods produce almost identical results (there are only a few places where >> the two lines do not coincide), and the numbers generated are a bit more >> than 1.6 times the simple average numbers in the summer and well over twice >> the simple average numbers in the winter. This additional seasonal >> difference is, of course, a result of the non-zero winter averages not >> being 'diluted' by the zero values from the longer nights. The results of >> the two more complex averaging methods make more sense to me as a way to >> present solar radiation readings for long time-periods. Non-zero averaging >> is computationally simpler and would probably be my preferred way to go. >> >> For UV radiation, the picture is rather different. Here, the simple >> average numbers are again lowest, but the other two averaging methods >> produce substantially different results, with non-zero averaging giving >> (particularly in the winter) results up to three times those generated by >> non-zero averaging. Here, I think daytime averaging makes more sense. As I >> indicated in my earlier post in this thread, I thought that non-zero >> averaging for UV radiation was likely to produce 'average' results that >> were distorted by periods of sunshine during an otherwise cloudy day, and I >> believe that this is a substantial contributor to what is happening here. >> Assuming, however, that stations which have UV sensors generally also have >> solar radiation sensors, it might be computationally simpler to average UV >> radiation readings if/when the accompanying solar radiation values are >> non-zero. >> >> Any thoughts or comments? >> >> On Saturday, March 11, 2023 at 4:05:18 PM UTC-5 Peter Fletcher wrote: >> >>> When looking at some of my 'yearly' charts (see >>> https://fletchers-uk.com/weather/index.html), the other day, I was >>> struck by how low the 'peaks' in the Solar Radiation and UV graphs were. >>> On a sunny day in the summer (yes - we do have such days in Buffalo!), I >>> typically see Solar Radiation numbers above 900 and UV values above 7 >>> for at least a couple of hours around solar noon, but the peaks of the >>> yearly graphs barely exceed 325 and 2, respectively. A (very) little >>> thought revealed the reason for this - the longer term charts average >>> the raw values recorded over periods of more than 24 hours (a week, in >>> my case), so the averages displayed on the charts include a large number >>> of entirely predictable nocturnal zero readings. In the depths of a >>> Buffalo winter, it is dark for 15 hours out of the 24, and even in high >>> summer here it is dark for a bit less than 9 hours out of 24. >>> >>> 'Straight' averages are easy to compute, and make reasonably good sense >>> for displaying the majority of weather-related measurements, which >>> typically have no particular diurnal pattern - or, at least, not such an >>> extreme one - but it doesn't seem totally to make sense to use them when >>> you know in advance that there is such a pattern. OTOH, it clearly >>> wouldn't be very useful just to record and display the daily peak values >>> for these measurements, since that would treat otherwise cloudy days >>> during which the sun appeared through the clouds for ten minutes around >>> noon in the same way as days on which the sun shone out of a cloudless >>> sky from dawn to dusk. Some averaging is needed. >>> >>> One possibility that might produce (IMHO) more meaningful results is >>> 'non-zero averaging' - do not count zero values in computing the >>> average. Solar Radiation rarely reads as zero during the day, so the >>> results of this calculation should correspond reasonably well to a >>> daytime-only average. Daytime UV readings, OTOH, are frequently zero if >>> it is reasonably heavily overcast, so 'non-zero averaging' would produce >>> misleadingly high 'average' values on days with variable cloud cover. >>> >>> A second, and, I think, better, possibility would be to explicitly >>> record and average only daytime values for both readings - defining >>> daytime as being between sunrise and sunset for the date and the >>> station's location. >>> >>> It might also be of interest to record and display the average daily >>> number of minutes/hours for which the reading exceeded a particular >>> threshold, and/or the level reached for at least a certain length of >>> time - the thresholds in each case being determined in advance - but >>> computing these results on the fly would likely be more challenging. >>> >>> I am going to be playing with implementing these ideas over time, but I >>> would like to hear others' thoughts. >>> >>> -- >>> >>> Peter R. Fletcher <[email protected]> >>> Home Page - https://pfletch.fletchers-uk.com >>> >>> -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/30d951f2-3d16-4e0b-aa66-a29ad3507ac9n%40googlegroups.com.
