Correcting Extremes: Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search
1,923 bytes added ,  10:37, 26 July 2021
m
→‎Introduction: restored accidentally deleted cell
m (→‎Introduction: restored accidentally deleted cell)
(2 intermediate revisions by the same user not shown)
Line 40: Line 40:
|[[Webtags#Monthly|thismonth.htm]]
|[[Webtags#Monthly|thismonth.htm]]
| Please see [[#Accuracy Note]]  
| Please see [[#Accuracy Note]]  
|-
|colspan="5" style="background:pink;"|monthyyyyMM.ini are archived copies for past months
|-
|-
! scope="row"|For current year-to-date
! scope="row"|For current year-to-date
Line 45: Line 47:
| Editor for "This year's records"
| Editor for "This year's records"
|[[Webtags#Yearly|thisyear.htm]]
|[[Webtags#Yearly|thisyear.htm]]
| Please see [[#Accuracy Note]]  
| Please see [[#Accuracy Note]]
|-
|colspan="5" style="background:pink;"|yearyyyy.ini are archived copies for past years
|-
|-
! scope="row"|For all readings since a '''start date''
! scope="row"|For all readings since a '''start date''
Line 57: Line 61:
| Editor for "Monthly Records"
| Editor for "Monthly Records"
|[[Webtags#Monthly_All_Time_Records|monthlyrecord.htm]]
|[[Webtags#Monthly_All_Time_Records|monthlyrecord.htm]]
|
| Similar to previous row, but different start date, and separate extremes maintained for each month (regardless of the year)
|}
|}
Explaining columns in above table:
Explaining columns in above table:
Line 68: Line 72:


The editors built into Cumulus, for long term extremes (over a period of a month or more), give you the ability to display, for each extreme record:
The editors built into Cumulus, for long term extremes (over a period of a month or more), give you the ability to display, for each extreme record:
# The figure taken from a search for that extreme by examining all entries in the [[dayfile.txt]] for that period
# The (hopefully more accurate) figure taken from a search for that extreme by examining all entries in the [[dayfile.txt]] for that period
# The figure taken from a search for that extreme by examining all entries in the [[Standard log files]] for that period
# The (usually less accurate) figure taken from a search for that extreme by examining all entries in the [[Standard log files]] for that period


Normally the first returns the more accurate result (unless the '''dayfile.txt''' line, either was created with a rogue value, or has been corrupted). Let me explain why:
Let me explain why the first returns the more accurate result (unless the '''dayfile.txt''' line, either was created with a rogue value, or has been corrupted):
* Using [[Standard log files]] as source for recalculating past extremes:
* Using [[Standard log files]] as source for recalculating past extremes:
** Let us assume you are using the default logging interval of 10 minutes
** Let us assume you are using the default logging interval of 10 minutes
Line 98: Line 102:
==Why might your extremes need to be corrected?==  
==Why might your extremes need to be corrected?==  


If there is a [[Correcting_Extremes#Rogue_value|rogue value]] read from your weather station (this could be due to noise affecting communications, or because a sensor has been knocked), it can get into any of those extreme record files and it might also make related derived value extremes wrong as well.
Sometimes a mistake is made in setting up or calibrating a sensor, or (despite the warnings within both flavours of Cumulus about getting your choice of units correct from the start), you decide to change your units. In both cases, you will identify a constant/multiplier adjustment to be applied to adjust all values (luckily times and dates of extremes are not affected) over the past period. In both cases, you need to correct past entries in any [[Extra Sensor Files]], any [[Standard log files]], in [[dayfile.txt]], plus the multiple [[Category:Ini Files|extreme record files]].
 
'''The instructions on this page will help you correct the extreme record files''' as there are relatively few edits to do for a single source value changing because of units, or a calibration multiplier. There is no change to when a maximum/minimum occured, nor does it affect any derived values.  For example a change in units, or calibration multiplier, for temperature or wind speed, does not affect calculations for wind chill and feels like temperature.  It is a bit more complex if you change a calibration offset, as that might affect threshold for calculation of some derivatives (e.g. changing an offset for temperature or wind speed also affects wind chill).  It is slightly more complicated changing units for temperature (as you may have many extra temperatures).
 
The easiest way to change entries in any Extra Sensor Files, any Standard log files, and in dayfile.txt, is to either write a batch editing script (see [https://cumulus.hosiene.co.uk/viewtopic.php?p=155539#p155539 changed rainfall units example]), or to use a spreadsheet (be careful not to affects dates or times) like '''Libre Office Calc''' where you can paste special a multiplier to all cells in a particular column.


It is also possible that you have discovered that you made a mistake in setting up or calibrating a sensor, and this leads you to identifying a constant/multiplier adjustment
If there is a [[Correcting_Extremes#Rogue_value|rogue value]] read from your weather station (this could be due to noise affecting communications, or because a sensor has been knocked), it can get into the daily summary file,  any of the extreme record files, and any related derived value extremes may become wrong as well.
to be applied to adjust all values over the past period.


A sensor might fail, and Cumulus does not recognise that "Null" (this might mean the weather station sends all bits set to zero or all bits set to one) values should be ignored when comparing against existing extreme records, and so set the extreme record to zero or maximum number that the number of bits can convey.
A sensor might fail, and Cumulus does not recognise that "Null" (this might mean the weather station sends all bits set to zero or all bits set to one) values should be ignored when comparing against existing extreme records, and so set the extreme record to zero or maximum number that the number of bits can convey.
5,838

edits

Navigation menu