Month.ini: Difference between revisions

PleaseThe Cumulus 1.9.2 beta releases were the first appearance of monthly (and yearly) extreme record tracking. The release announcement when 1.9.2 came out of beta (see https://cumulus.hosiene.co.uk/viewtopic.php?p=51829#p51829) forstarts detailsby aboutexplaining how to use the new high/low editing screen for initialising the extra extreme records addedincluded toin the new file '''month.ini''' inthat formed part of this release.

Month.iniWithout containsgetting thetoo highesttechnical, dailysome valueof forthe certain derivativestime-stamps in thethis month,file thoseare dailyin valuesa are supposedspecific to beCumulus accumulatedtime-zone, overthat afor meteorological9am/10am dayrollover, sodiffers from the accumulationtime-zone resetsof atthe rolloverhost timecomputer. DueIn tothis ainternal programmingprocessing bugtime-zone, somethe weredate resetpart atis midnighta irrespective[[Meteorological ofday|meteorological actualdate]] rolloverand the time. part Prioris tozero build(00:00) 1048at thisrollover, meantso that fora thosetime usingpart 9am/10amshown rollover,as wind03:00 runactually accumulatedrepresents betweennoon midnighton andthe rollovercomputer wasclock assignedwith Cumulus 1 set to rollover at 09:00 on the followingcomputer dayclock. Against that Equallybackground, some values where peaks at a particular time were tracked in this file,. Cumulus was supposed to convert the internal time-stamps to computer clock equivalents for outputs in web tags (the date logged was adjusted to the correct calendar day, butthe betweentime midnight and rollover it should be assignedadjusted to meteorologicalcorrect datetime (thewithin previousthat calendar dateday). to ensureUnfortunately, peaksthis weremeant notfor assignedextremes totimed wrongbetween month.midnight and Therollover fullon descriptionthe offirst bugsday wasof nota recordednew asmonth, itCumulus was assumedassigning everyone updatedthem to fixedthe buildnew month, andinstead peopleof didthe notold caremonth, aboutbecause pastthe recordsconversion (Cumulusfrom 1internal atmeteorological thisdate stage(the discardedprevious records forcalendar past monthsdate). in Itthe wasprevious subsequentlymonth discoveredto thatcalendar the(computer bugsclock) weredate nothappened fixedtoo completelyearly in buildthe processing 1048sequence!

OnLater builds of the endlegacy ofsoftware monthdo roll-overa back-up folderas at start of day. This means when the month changes, Cumulus stores the '''month.ini''' after it has been initialised for the new month. No copy is retained of the month.ini at the end of the month.

From build 3035 onwards, MX archives the month.ini and year.ini file at the end of the month/year as monthYYYYMM.ini and yearYYYY.ini. This means that although the file saved in the back up daily folder contains the month.ini for the new month and so does not back up the end of month position, the old monthly log ini file is preserved for true end of month state in the data folder with a new name.

== Retaining month.ini after month changes ==

[[File:Badge vMx.png]]InAs mentioned [[#Cumulus MX, version 3.0.0 onwards|at end of this section]] Cumulus MX retains the file at the end of each month,. the The final ''month.ini'' for that month is renamed '''monthYYYYMM.ini''' (where YYYY denotes the year using 4 digits and MM denotes the month using two digits) e.g. ''month201703.ini'', thus ensuring that statistics for all past months remain accessible.

[[File:Badge v1.png]]ThereAlthough isCumulus no1 obviousresets facility''month.ini'' at the end of each month, without saving the file [[#Cumulus version 1.9.4: From build 1089 to achievefinal aCumulus similar1 retentionbuild|see automaticallyhere]], it is possible to view old months using [[Cumulus_Screenshots#View_data|screen]] provided in Cumulus 1,; althoughthat allgenerates thea informationsimilar can(but not identical extreme records) set of bemonthly generatedderivatives by doing calculations from the relevant lines in dayfile.txt. If you want such information on a web page, then some JavaScript code (as explained in support forum posts) can parse a copy of [[Dayfile.txt]] uploaded to your web server, and do the equivalent calculations. If the daily summary is available in a database table, then those calculations are very easy to code in SQL. ifFor thethose dailytechnically summaryable, there is availablean easy work-around to save month.in on a databasemonthly basis using the "extra files" feature. However,It thereworks because you can include "<currentlogfile>" in a remote path. Please note that this is an inefficient process (because there is no facility within Cumulus 1 to perform an action only when month ends, and this technique therefore adds an action each time Cumulus does an update) work-aroundprocess, usingbut theit "extrais files"easy featureto that you can include "<currentlogfile>"implement:

This will save a file with a name like '''monthMar19log.txt.ini''' in your data folder. Note that there might be changes to month.ini after the last time the above work-around copies it, because the copy happens one update interval before the end of the month rollover and so will not pick up any extremes recorded in closing seconds of the month.

You have probably worked out that the attribute ''Speed'' in the examples in the above table is the maximum wind speed, that ''Gust'' is the maximum gust speed in the month and that ''Windrun'' is the maximum daily wind run. Those are the three rows that appear in the wind section of the table in the '''thismonth.htm''' web page. But you might be puzzled that the web page only shows a date for the maximum daily wind run, yet the month.ini entry includes a time. All that means is there was no wind after that time on that day, in Cumulus 1 if you edit your template '''thismonthT.htm''' and specify ''<#MonthWindRunHD format=HH:nn>'' you will see the time appear instead of the date. Put simply, the date/time entry is when Cumulus last updated that figure. In this particular case its calculated wind run never exceeded that figure in this month, so the entry has not been updated. Similarly, highest daily rainfall tracking includes a time, representing the final updating of the total on the date reported.

The diagnostic logs (for cumulus 1 in [[Diags folder]]) record before and after values for updates to highs and lows for monthly and annual extreme records, and can help if this file is corrupted by a false extreme. TheMX storeddiagnostics valuesdo canreport bewhen corrected"month.ini" inis Cumulusupdated, 1but usingthey the 'don'Thist month's(at records''time screenof ontyping thethis) '''Edit'''record menu.what Inwas MXupdated, theso equivalent editorthere is accessedno viabefore theand user interface you see in aafter browsertracking.

[[Category:LogIni Files]]