Cumulus Support

@sjmcinness:

[...] Saw that beteljuice gave you some advice above. You may want to follow his advice as he's responsible for the beteljuice-interface you're using If necessary I'll make some changes.

Reading backwards I noticed the beteljuice remark on the website was aiming at @hills so, ignore

Hi,
Is there a way to ignore the (old) dayfile empty fields ?
I have this DOS display : log :

2020-01-05 16:14:34.285 CumulusUtils : Line read from dayfile.txt added to MainList:
15/03/04,23.8,183,14:30,4.1,07:26,13.5,16:06,1027,18:26,1032,08:59,0,09:00,0,8.8,0,9.4,12:36,36,15:56,86,07:16,0,0,18.6,14:26,17,15:26,2.1,03:45,0,00:00,3.8,03:45,5.2,13:46,1.5,04:05,196,7.2,0,0,00:00,0,00:00,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
2020-01-05 16:14:34.285 DayfileValue constructor start
2020-01-05 16:14:34.285 Dayfile : ReadLine Start
2020-01-05 16:14:34.285 CumulusUtils : Line read from dayfile.txt added to MainList:
16/03/04,21.6,213,15:45,4,07:28,17.3,15:15,1030,17:56,1033,08:59,0,09:00,0,10.7,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
2020-01-05 16:14:34.286 DayfileValue constructor start
DayfileValue.SetValues fails: Le format de la chaîne d'entrée est incorrect.
DayfileValue.SetValues fails: Need latest dayfile.txt filled correctly with data
2020-01-05 16:14:34.300 Dayfile destructor: Closing file and ending program
2020-01-05 16:14:34.302 Ini Flush cache modif:False, cumulusutils.ini

Thanks

@laulau:

Is there a way to ignore the (old) dayfile empty fields ?

No there is not but I may be able to adjust the reading of the file such that it is possible to continue. Otherwise you will have to remove to erroneous lines yourself.

Send me your dayfile.txt and cumulusutils.log (PM) and I'll analyse it. Also give me your sysinfo and cumulus version.

Cheers, Hans

Wow!! for 5/1/2020, your software prediction was 348.83. then after my dayfile was created at 9:00am the actual was 341.15. I'm very happy with that accuracy for a prediction!!

A colleague of mine uses cumulus and lives at Surrey Downs, I'll ask him to implement cumulus utils so we have another close station for comparison.

hills wrote: ↑Sun 05 Jan 2020 10:40 pm A colleague of mine uses cumulus and lives at Surrey Downs, I'll ask him to implement cumulus utils so we have another close station for comparison.

He is still in the process of tidying it up, but initial install is here: http://wood-ward.com:8080/weather/pwsFWI.html

hills wrote: ↑Mon 06 Jan 2020 3:36 am

hills wrote: ↑Sun 05 Jan 2020 10:40 pm A colleague of mine uses cumulus and lives at Surrey Downs, I'll ask him to implement cumulus utils so we have another close station for comparison.

He is still in the process of tidying it up, but initial install is here: http://wood-ward.com:8080/weather/pwsFWI.html

Hi there - as Phil said, i've got the basics up and going here:

http://wood-ward.com:8080/weather/pwsFWI.html
http://wood-ward.com:8080/weather/maps.html

I'll look to have a static file created soon.

Cheers.
Michael

@hills: Thanks! Spread the word!

hills wrote: ↑Sun 05 Jan 2020 10:40 pm Wow!! for 5/1/2020, your software prediction was 348.83. then after my dayfile was created at 9:00am the actual was 341.15. I'm very happy with that accuracy for a prediction!!

That precision is of course kind of chance knowing the precision of weather predictions .
But I did make a short analysis and thanks to meteosangonera and PaulMy a better insight into the effect of prediction could be made.

Hi all

I have taken an alternative approach in displaying the Bushfire Danger level on my website. It, in macro, is to take the forecast bushfire danger by the Australian Bureau of Meterology for my area (which happens to be suburban Brisbane) as an XML file from the BOM website and show it on my Saratoga PHP Scripts /Cumulus website - URL is https://www.kstwx.net/index.php

If anyone is interested in the detail of how I have done it, I am happy to share it here.

My approach is: if the experts at the BOM have already done the assessment why try to reinvent the wheel! Having said that, it clearly is not applicable to sites outside AUS.

Best wishes,
Keith

Good question Keith.

My reason is because my firedanger warning area - Mt Lofty Ranges, covers a lot of different types of terrain and to a degree different climates. I live in a particularly damp area as the hills behind us cause more precipitation here than most other locations in the Mt Lofty Ranges, so I wanted to be able to compare my "micro climate" to the rest of the area. In fact this is also the reason I got my own weather station in the first place and having previously been in the CFS, it was something I was toying with doing myself. Luckily someone with a lot more programming skills than I have beat me to it.

That said I still pay attention to the BOM rating and therefore am interested in what you've done.

griffo42 wrote: ↑Mon 06 Jan 2020 7:59 am My approach is: if the experts at the BOM have already done the assessment why try to reinvent the wheel! Having said that, it clearly is not applicable to sites outside AUS.

There are several reasons - as a meteorology amateur - as why to have the local Fire Weather Index for PWSs on your site (without even trying to devalue the BoM work, I know what's behind it and what they do!):

1. The BoM predictions and warnings are for a vast area and may not directly apply to your own situation. The discussion on Crafers is clear on that issue.
2. Dealing with the warnings yourself makes you think more conscious about the process of fire and the dangers involved (making you probably more careful)
3. Having a local warning on your PWS can be seen as a trigger to look at the BoM messages more careful.

Fireweather will become more and more important. Amateur meteorologists deal with everything and measure everything (from sunrise to rain to air quality) so why do that? Why not just say: oh somebody else (the government) does it already, why would I do it? Thinking about phenomena in the environment is good, It enriches your mind to rethink.

And indeed, the world is bigger than AUS (I am Dutch). And everywhere they use similar but different and very complex warning systems. Mine is uniform, cheap and I claim validity everywhere. Usefulness is different: having a meteostation with pwsFWI in the middle of the Sahara or in the centre of Australia is clearly not useful though my guess is that the warning level would be extremely high.

Anyway: local check does not stand against the BoM warning. So you can use both beside each other. Check one after the other and wonder: why the difference. To do so you have to understand how both warning systems work. So you have to study, think about the science behind the warning, about the causes of fire. If my warning and accompanying blogs trigger that, I am successful.

Edit: and what @hills says above, he was first

@gti138:
Hi, missed your reaction because of the sudden discussion. Thanks for using pwsFWI. I did put you in the list as well. Looking forward to your updated site.
Clearly you have other surroundings than Northgate, closer to the hills but also urban effects, please do provide some context in the header. It would not surprise me if there were also effects of placement of instrumentation as well (close to a building, sheltered of wind) which may have effect on the calculated value of pwsFWI. Difficult to know from here.
Cheers, Hans

Version 2.1.0 is online.

Although the user probably won't find significant changes, there are two places where the data handling got a big overhaul: reading the dayfile.txt file and in creating the top10 list. In the latter I used single statement LINQ queries i.s.o. the more low level approach I used from my prior C-implementation (the top10 list was the very first part of CumulusUtils). The dayfile.txt reading has been cleaned from redundancies and made more efficient.

I have a question for the users (as a consequence of the issue by @laulau above):

So far several problems have occurred with the data in dayfile.txt, three types:

1. Illegal format for the time of a value (e.g. '7:00' i.s.o. '07:00')
2. illegal value for a number, which triggers an overflow event
3. An empty value

I implemented an error handling where the assumptions are:

1. The user will be informed of all errors and their exact location through a message in the logfile for all errors detected;
2. If there is more than one error in a line, only the first error is reported after which the next line is read; there is no inline recovery (so far, maybe I'll find a way for that and show all errors in a line in one pass). This may lead to problems further down the road and may require serious editing of the dayfile. Does there exist a dayfile editor?
3. It is up to the user to eventually correct the errors or live with the skipping of the line / automatic corrections.

The challenge is to continue the program and present the data anyway, supposing the good data will be the majority.
Knowing the field in which the error occurs, I think I have the following options:

1. Abort execution on encounter of the first error (default)
2. ignore the line with the erroneous data completely and continue with the next line (which is the option currently implemented)
3. Choose a value for that field which would blend in with the other values (e.g. take the value for the erroneous field of the day before. Incorrect but still there is a result to show). If you have a series of many days with errors, that may lead to strange graphs but at least you know you are missing something.

So my question to the users: how would you want recovery to work or would you skip CumulusUtils because correcting dayfile would be too much work.
And how do other dayfile readers deal with errors like this?

NOTE: this does not mean CumulusUtils is a generic dayfile checker because it does not use all the fields.

Ignore the line with the erroneous data completely and continue with the next line (which is the option currently implemented)
Piotr