The past months I blogged several times about my Fire Weather Index for personal weather stations on the basis of Cumulus as data acquisition software. So if you’re new here and don’t know what pwsFWI is about, check out the previous blogs on the subject. Currently, pwsFWI is part of a small software package named CumulusUtils. This meteo website/blog is the home of the package which is distributed through the Cumulus support forum. If you have a weather station which can cooperate with Cumulus, don’t hesitate and get it, it’s free.
So pwsFWI is a module in CumulusUtils and has currently reached version 1.8.0.
A simple explanation of what is does is as follows. The algorithm, originally developed by me, contains basically a meteorological calculation of of the drying conditions to which the vegetation is exposed.
- Dryer conditions increase the risk to fire.
- Higher temperatures increase liberation of water from the fuel (the live and dead vegetation).
- Wind transports water away from it’s containers keeping the driving force for evaporation present.
- Wind also increases risk for spreading fire once it exists, it pushes sparks and heat to fuel which has not ignited yet.
The above four points show the factors taken into account for calculating a risk. But risk does not only increase, it also decreases. Fire risk decreases by absorption of water (humidity), I call this quenching. Water becomes available by rain (or flooding but flooding or human intervention is not taken into account).
The vegetation itself, dampens the effect of evaporation and quenching. That means that the fire risk won’t go up or down in big shocks: it takes time to reach a high risk level or to come back to a low risk level. The algorithm which takes this into account, I call smoothing.
Without explicitly publishing the algorithm I can say that the public trials which are going on (from September 2019) show that the pwsFWI is performing very well in the company major, nation wide warning systems (with test sites currently in Australia, Spain, France, Poland, Canada and The Netherlands, see here).
Then there was the question of : what will happen the next coming days?
The case for prediction
Personally I am not a fan of prediction: the system is based on a strict calculation and vegetation – specifically forests – will not change their fire condition in an hour or overnight. In my view the current status is enough to demonstrate the risk of a forest to ignite. However, several users pressed a little to have a prediction. Especially the fact that pwsFWI is calculated and displayed on yesterdays date, gave the impression it was lagging behind. And in a way it is of course, but apparently, where I thought and argumented that it did not matter, it actually did matter: because it set in peoples minds. It is actually interesting, that the two test sites which have their station in semi-arid areas (Phill’s Backyard and Meteo Sangonera) were the great pushers for a prediction addition.
So for the perception of the pwsFWI, of what it is actually saying. A prediction of some kind is required.
How to predict
The big question with weather prediction is: how do you do it, what model do you use? Building your own prediction model is bit too far fetched to put it mildly, so you need external interfaces to existing models. And those exist. Actually, I had already been looking at DarkSky and similar prediction interfaces, but then meteosangonera came with a freeware API interface. An easy to use interface based on the most renowned models which works globally. PWS owners can take an account, look for the location of their station (or closest to their station) and they basically can look what the weather will be five days ahead. I am not talking about the quality of long term predictions, that is another discussion, so I simply decided to go for the yourweather.co.uk XML API for 5 days with 3 hour interval predictions.
How did I enter the prediction into the software, without having to turn it all upside down, with the standing system being in tact? To appreciate that, you need to understand that the core, the backbone, of CumulusUtils is the dayfile.txt file, containing all (average, min, max) data per day for that specific station. When needed it can make use of the monthly logfiles.
The programming consisted of the following steps:
- Have the user enter into the prepared cumulusutils.ini file the following entries:
- predictionURL; This contains the value of their localised URL, to use for querying the API
- PwsFWIPredictionMessage and PredictionBackground; Text and colour needed for the presentation in the web interface.
- When the user runs the pwsFWI module, it gets the XML data which belong to that specific location.
- Extract the required data from the XML API and create an additional entry to the dayfile list. Five entries will be created like this for the five days in the prediction interface.
- Run the calculation of the pwsFWI on the basis of the extended list of dayfile values and create the pwsFWI list of values.
- With the pwsFWI list of values, generate the web page for pwsFWI. Separate the predictive values from the passed values by a thin red line in the table and give the predicted values a different background, display the message that prediction is active.
- Remove the predicted values from the dayfile list so other modules don’t get confused.
That’s it. Although written like this it looks a bit simpler than it was.
Having implemented the prediction as above, there appeared to be a technical problem: two sites had an issue in the sense that the prediction procedure did not finish with the exception message that the input string was not correct, it was not clear which string was meant. After analysis, it appeared it was [probably] caused by the combination of inaccurate programming and users using older version than my reference version for development. It seems that the Xml.Linq library had some differences between versions. The problems were solved, when I ran a code analyser and worked away all warnings concerning formatted ToString() calls, with either current culture or invariant culture format. Very educational.
In a way it is great that C#/.NET results in extremely exchangeable software, which even with small deviations to the standard simply keeps on functioning on the defaults (apparently). But when more versions operate in a great variation (Linux, Windows 7 – 10) a problem becomes more difficult to locate and more difficult to debug. Interesting though.
We’re now in version 1.8.3 and it seems all to be working OK. The testing is back on the meteorological level, trying to find out how much a two day ahead prediction will differ from the actual calculation when the day has past.
I will report on that next time.