Ever wondered how the Glendale App works? How does it achieve such unrivalled accuracy? How can a teuchter on Skye claim to have created the world's only 100% accurate aurora alert app?
I am going to try to explain a little about what goes on behind the scenes and what it is actually doing.
The first version of the app was released in November of 2015. It included the live reports, IMF and Solar Wind panels. All alerts had to be done manually. I would take test photos regularly and then manually send out push alerts on the app and Twitter once I had picked up the aurora.
In December of 2015, I applied for permission to use live data feeds from the Tromsų Geophysical Observatory's magnetometer array and, in January 2016, they very kindly granted me access on the condition that their data is not used for commercial gain. This allowed me to fully automate the app and produce the most accurate forecasting and alert system that exists anywhere in the world.
The Iceland version of the app was released on January 17th, 2018, together with beta versions for all north European countries.
Final calibration of the Scandinavia version of the app was completed in April 2019. Some investigative work on a Greenland version of the app was started in the summer of 2019. Initial trials of the app in Canada were done in October 2019.
It was clear from the research that I had been conducting for many years here on Skye that accurate, automated aurora alerting and forecasting were achievable, given access to the relevant data feeds. I wanted the technical challenge of proving that it could be done, validating my own research and, ultimately, producing a tool that would give aurora-hunters the best possible chance of catching them.
There were some specific things that I absolutely wanted to avoid: sending alerts during the day and regurgitating data from the SWPC. Everything on the app must be processed to add some value. Only information that is actually needed to predict auroras should be included.
The app uses live data feeds from (at the time of writing) eleven magnetometers in Norway and one in Sweden, together with satellite data from DSCOVR, ACE and STEREO-A.
It also uses the real-time sun/moon position and twilight times which I calculate in the app rather than relying on external sources.
Live sighting reports are submitted by registered users of the app.
All client/server communications use Ajax and JSON with minimal packet sizes to ensure optimal performance on 2G and 3G mobile networks.
All features are load-on-demand to keep bandwidth usage to an absolute minimum, whilst still allowing all critical data to refresh at one minute intervals.
Once a minute the app pulls the latest data from the magnetometer array, DSCOVR, ACE and STEREO-A. The satellite data is adjusted for impact time at the Earth and sorted into order of arrival. This gives the most accurate possible picture of what is happening within the Earth's magnetosphere at any given moment. Additional derivative data are also calculated, including clock angle, dynamic pressure and energy transfer into the magnetotail.
The app is automatically monitoring the data feeds for failure and will automatically switch in alternative sources in the event that a feed goes offline.
The first iteration of my substorm tracker used a 2D signature scanner on every magnetometer feed. The signature scanner was analysing deflections on the magnetometer over time, to identify which phase of the substorm we were in. The outputs from the multiple 2D scanners were then combined to determine when the alerts needed to be issued.
2D scanning had many flaws and inefficiencies. The most notable being that it wasn't easy to create a single figure that represented the overall strength of the substorm at any instant. This made it very difficult to compare different substorms to identify which was stronger.
I have since developed a 3-dimensional scanner, which analyses slices across the magnetometer array: deflection vs time vs latitude. Picture the TGO stackplot graph as a landscape with hills and valleys. This algorithm is extraordinarily complex and has taken me over a year to perfect. The outputs it produces, however, are very simple and useful: the strength and the latitude of the substorm... and, therefore, by proxy, the strength and latitude of the aurora.
My 3D substorm tracker is similar to the Ovation Model that you will see on many sites, except that mine is measuring where the actual substorm/aurora is, rather than trying to guess where it might be based on satellite data. Unlike the Ovation Model, mine is taking account of the substorm process.
The latest work I have in hand is an extension to my model which calculates the width of the aurora in degrees of latitude. This allows me to make a fairly accurate estimate of the angle above the northern horizon to which the aurora will extend from any viewing point.
At the end of each substorm, the app automatically creates a spreadsheet containing all of the collected data in the 36 hours upto and including the subtorm, together with detailed parameters from my model. This allows me to analyse the performance of the app and models in detail afterwards. It allows adjustments to be made and then 'replayed' against the real data to further refine the model.
Having sorted the satellite data by arrival time and calculated all the derived values, the app scans the IMF and Solar Wind to identify patterns that will cause a substorm to develop. e.g. prolonged periods of negative Bz.
The app also scans for forward and reverse interplanetary shock signatures and will issue an alert within minutes of a shock arriving at the satellites.
My subtorm tracker allows the growth, onset, expansion and recovery phases to be clearly differentiated. This allows usually a few hours advanced warning to be given that a substorm is developing. The IMF and wind analyses allow this to be extended slightly earlier.
The 27-day long-range forecast is usually accurate within 6 hours if the coronal hole stream remains of similar scale. This is in spite of the day/night shift that occurs on each rotation.
All forecast and nowcast information on the app is personalised to the user's location. The complex, generic model data and analyses are calculated once per minute and cached. They are then personalised and adjusted for every user's precise location. Every location in the UK, Europe and Iceland will see their own specific nowcast.
All conditions of endless twilight and the sun never rising/setting are catered for, so that the nowcast can advise when auroras are impossible.
This table shows the average amount of advance warning it gives, in hours, for substorms that go on to reach yellow, orange, red or major levels:
|Mean Times From...||Yellow||Orange||Red||Major|
|Start to Onset||2.00 hours||2.62 hours||3.30 hours||4.20 hours|
|Start to Peak||4.25 hours||5.80 hours||7.60 hours||9.00 hours|
|Onset to Peak||2.25 hours||3.18 hours||4.20 hours||4.80 hours|
Take, for example, a modest substorm that reaches 'yellow' alert levels only. The app will begin advising that a subtorm is developing 2 hours before it issues the onset alert. Once the onset alert has been issued there will typically be another 2.25 hours before the substorm reaches its peak. This is plenty of time for people to drive to viewpoints should they need to.
The stronger the substorm eventually becomes, the longer it takes to develop, so my app will give much more advance warning that a strong aurora will happen.
Registered users can make live reports by clicking buttons for 'aurora', 'nothing' or 'cloudy'. I stick rigidly to the 'on camera' rule for UK users, as this helps reduce the number of false reports. For latitudes above 63N the app switches to naked eye reporting and forecasting.
The app automatically validates every aurora report using a complex set of criteria. Some reports it will reject immediately and others will be flagged as 'maybe' and displayed with a question mark. The app automatically notifies me of the borderline reports, so that I can approve them manually.
The commonest causes of dubious reports are during twilight start/end and around the moonrise/set, so inexperienced users may have these reports automatically flagged by the app during those times.
The other cause of dubious reports are when there is no, or minimal, geomagnetic activity and again the app will automatically flag up these reports for moderation.
In all of these cases, the app is making a complete assessment of the situation at the time of the report including the sun & moon positions at the user's precise location and the current substorm progression.
Users are graded, using a star-rating system, based on the accuracy and frequency of their reporting. This gives other users of the app confidence that a report can be trusted. These experienced users are given more tolerance in the validation of their reports to ensure that vital edge-case sightings do not get flagged as dubious or rejected.
During the night, the app displays the latest live report from each user. Up until November 2017, it would show the same during the day but there was some bogus coverage on social media that the app was sending red alerts unnecessarily when the map only showed ticks in the north the day after. This was because the users in the south had stayed out until the aurora faded and then posted a cross (nothing). To mitigate against this mistaken perception of poor performance, the map now shows the latest ticks during the day to give a proper summary of the successes during the previous night.
In September 2019, I added an advanced button panel, accessible only by an 'Easter Egg', that allows trusted users in the UK to report a little more information about the type of aurora they are getting, e.g. diffuse, rays, arc or overhead. This was for a trial to allow me to collect more data that would allow me to improve the forecasts in future years. If this data proves useful to my research then I will extend it to other countries and possibly allow even more details about the aurora type to be submitted.
The app has versions for Iceland and all countries in northern Europe. If it has the user's position, it will automatically switch to the correct forecasting engine for their location. For latitudes above 63N the app gives advice based on naked eye and below that it gives advice based on camera.
The work on the Iceland Version began in September 2017 in collaboration with Caroline Weir, an experienced and like-minded aurora-hunter, who is based in Reyjavik. Caroline provided extremely detailed logs of the aurora's elevation, strength and characteristics at different times during substorms. This allowed my existing UK model to be extended to provide incredibly accurate substorm tracking up to latitudes around 67N.
The data from Caroline was also essential in filling in some gaps in the UK model where on a few isolated occasions aurora-hunters were able to detect aurora in the sky ahead of the model.
In December 2018, work began on calibrating the app for higher latitudes in Norway, Sweden and Finland. This was primarily done using all-sky cameras and live webcams, backed up by user reports on the app. By mid January 2019, the app was already producing extremely accurate results for Scandinavia, with minor adjustments and testing continuing until the end of the 2018/2019 season. In the 2019/2020 season, Darren Beardmore provided invaluable assistance with final testing and calibration of the app for the high arctic, whilst working as an aurora guide in Lapland.
In August 2019, Rachel Bibby from the Isle of Lewis became the first person to test a preliminary Greenland version of the app and got the first successful tick from Greenland.
In October 2019, Rebecca Douglas from Kent tested the app against an aurora in Canmore, Canada and showed that the app perfectly tracked the aurora in the sky. She became the first person to report on the app from Canada.
Onset alerts are the most difficult alert to issue. I have spent countless hours refining and perfecting these. They are essential for the higher latitudes (>63N), as they are the heads-up that the aurora is coming visible by the naked eye. They are more an advisory for the lower latitudes. The problem is that, when they need issuing, the magnetometers are close to ambient, so it is really important to determine the transition in the substorm phases accurately. It is also important not to spam the users with onset alerts when the magnetometers wobble around background levels before committing themselves.
Up until December 2017, I used dynamic alert levels. Yellow was not always -200 nT, for example. When the moon is stronger, the substorm needs to be stronger. However, when the user is further north moon becomes less of an issue, so I reverted to static alert levels to ensure that higher latitude users received their alerts sooner.
I can take account of all these things based on a clear, dark sky and a camera. It is impossible to take account of light pollution and weather conditions. I set the levels based on what is ordinarily achievable on a camera, in a dark place, in the UK, with clear sky. If the user's view north is over the UK land-mass (e.g Cumbria, Lancashire, the Midlands), then a red alert might not get them an aurora, whereas for someone further south in Norfolk or Lincolnshire, with views over the sea, it could.
The amount of processing required to issue individual alerts for every user's precise location would be astronomical, so I issue the same alerts to all users. I send multiple levels of alert, so if red is not good where the user is, they can wait for the higher level alerts instead.
In the earliest versions of the app I used only three alert levels: yellow, orange and red. These provided basic warnings for all parts of the UK but once the red alert was sent it left nowhere else to go, which meant that when a substorm escalated to more extreme levels users would not get alerted. I later introduced the major, severe and extreme levels that were calibrated at levels when aurora would become intense at UK-equivalent latitudes and had a high chance of going overhead.
The Progressive Web App (PWA) technologies were only just becoming available when I started the app. Google were early-adopters and started adding the capabilities to their browsers in summer of 2015. I wanted to create the app as a web app to give complete compatibility across all devices and platforms. Devices that did not yet support PWAs would revert to running the app like a web-site until their vendors had caught up with the new internet standards.
Being novel and state-of-the-art technologies they were buggy and documentation was poor, which meant an endless cycle of code rewrites and workarounds over the first 18 months of the app's development until they had stabilised.
Google were first to support push alerts on their Chrome browser for Android and PC but their initial version did not support payloads, which meant a very convoluted process to get the actual text message of the alert to the device. Next to support push was Firefox, and it supported payloads, but not push without payloads, which meant a complete rewrite of my push code. Then Chrome added push with payload.
Microsoft have committed to providing PWA support and push alerts by late 2018. Apple have a prototype version of Safari with very basic PWA support (service worker and cache APIs only) due for release in spring of 2018. They have not yet committed to implementing push alerts.
I was able to extend the capabilities of the app as new APIs became available, for example, I was able to add offline aurora reporting when Google implemented the background sync API into Chrome.
Once all the major vendors have provided PWA support, the app stores will effectively become obsolete.
I conduct detailed testing and analysis of the app's performance every night based against the actual aurora that I capture on camera, reports from users and posts on social media. The model is carefully calibrated against the actual aurora in the sky to ensure that the substorm strength figure tracks the aurora strength in real-time. The model has now become so refined that bugs and deviations become very easy to identify.
There are around 9000 people actively using the app and most evenings there can be over 1000 people permanently logged on every hour. The web server is taking over 100,000 requests an hour during big auroras and over 40,000 on a quiet night.
One of the important things about the app is that it is 'self-testing'. It displays the precise time when the substorm started, peaked and ended, so it is very easy for users to correlate that with their own observations.
There have been over 75,000 reports on the app and, again, it is very easy for people to see the correlation between the substorm progression and the live reports coming in on the app.
Feedback from testers in Iceland and Scandinavia has been that the strength of the aurora in the sky directly correlates with the trendline graph displayed in the substorm panel and the 24-hour substorm strength graph.
There is nowhere for me to hide. I am presenting all of the relevant information on the app that allows users to verify its accuracy themselves.
Six years of research and development has gone into the app. I spent the years from 2013 through to 2015 photographing the night sky at intervals of 5 to 20 minutes. The stages of the aurora were then correlated against magnetometer and satellite data. At the time, this involved using a ruler to measure the deflections on the Stackplot graphs and calculating the magnitude from the scales.
I analysed precisely which data sources and signatures were needed to produce visible auroras here on the Isle of Skye. I also looked in detail at the effects that twilight and moon had on the levels at which auroras became visible. I worked with photographers around the UK to determine how the various latitudes affected the visibility of the aurora compared to Skye.
The accuracy of the substorm tracker and my automated data recording & analysis systems allow me to test, behind the scenes, many of the common myths and theories about auroras. I program the app to automatically collect and analyse data that are needed to validate or disprove them.
One example of this is determining how the alignment and strength of the IMF during the growth phase of the subtorm affects the peak strength in the expansion phase.
When I can prove a theory, I will the incorporate the results of my research into the app.
The app is entirely self-funded. I pay for all server costs to make it free for everybody to use. The app carries no adverts and no SPAM is sent. No revenue is generated whatsoever. I freely give all my spare time to auroral substorm research, development of the app and technical support for users.
Originally written on December 19th, 2017. Updated on September 16th, 2019.