Well, the results are in. Earl weakened pretty significantly as he traveled up the east coast, resulting in fairly minor damage. The game had a lot of first-timers, and most of them did pretty well. I’m pleased with my own performance, but I’d rather win. There might be another chance shortly if the remnants of Gaston get back together.
Also, I finally made a page with a link to all of the scored games and added that link to the tropical weather page.
The hurricane season is in full swing, with three active storms. Danielle is scooting off to oblivion in the North Atlantic, but Earl is gearing up to take a run at the east coast…somewhere. As of this writing, the forecast track is such that landfall could be anywhere from the Outer Banks to Nova Scotia, or perhaps it may yet turn out to sea. Of course that means there’s a Funnel Fiasco tropical contest underway. You can enter by clicking the link on the tropical weather page (or go directly to it here). The deadline for entry is Tuesday at 8 PM EDT (Wednesday 0000 UTC). Just a reminder to make sure you enter valid numbers, I won’t check them for you.
Stay tuned for more on Hurricane Earl, and also for a potential repeat when Tropical Storm Fiona get closer.
While working on yesterday’s Weather Watch post, I decided that it was important to know what the normal river levels were this time of year. After all, knowing the river stage is pretty useless without context. Flood stage is pretty easy to find for most sites, but that doesn’t necessarily provide context for low-water situations. For example, the Ohio River at Louisville, KY (McAlpine Lock and Dam, lower) has a flood stage of 55 feet, so being 15 feet below flood stage is normal. In contrast, 15 feet below flood stage for the Wabash River at Lafayette, IN is four feet below ground. The concept of pool stage exists, but it’s not widely used. So how can river depth be put in the proper context for low-water situations?
Like most other data meteorological, a comparison to the average value over some period of time is apt. The question then becomes “where do I find the average river height for a particular site?” Of course, the average height can vary greatly over the course of a year based on local and upstream precipitation patterns, so month-by-month data is preferable. Unlike temperature and precipitation, though, the National Weather Service does not issue daily climate summaries for rivers (at least not that I’ve seen).
Fortunately for the numerically-minded, the United States Geological Survey (USGS) has a wealth of data available for free on the Internet. It’s a little tricky to navigate, but with patience, the National Water Information System (NWIS) will surrender the desired information. With data for approximately 1.5 sites available in a variety of readable and parseable formats, there’s enough to keep even the most efficient data nerd busy for a long time. For easier-to-navigate real-time hydrologic data and forecasts, see http://water.weather.gov/ahps/.
On Monday evening, Angie and I went chasing unexpectedly. While the storm produced some wind damage, I’ve been unable to find confirmation of a tornado (there was at least one real-time report, though). We saw very little of interest, until the incredible light show afterward. So I present to you a few boring cloud pictures, plus also the lightning:
http://weather.funnelfiasco.com/chase/21jun10
This is also kind of exciting because for the first time I’ve forgone the use of tables to layout the photos. The result is that the page renders based on what your screen wants it to, not on what I demand it does. This is supposedly a much less evil way to do things. In the future, I’ll be converting some of the older pages to work this way as well.
Further, I’ve updated some of the pages to reflect new license information. Instead of my custom written “you must have my permission” text, I’m now licensing content under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. It’s simpler, more enforceable, and more in line with my own personal values. There’s a blog post forthcoming where I muse upon licensing issues. In the meantime, know that the content on FunnelFiasco.com is under whatever license it says it is. I’ll work on updating the license text on pages soon. And maybe I should consider a more dynamic site (e.g. using PHP) so that I don’t have to keep making these changes on each. freaking. individual. page.
The number of meteorologists in the United States is very small. According to the Bureau of Labor Statistics, less than 10,000 people are employed as atmospheric scientists in non-faculty positions (anecdotal evidence suggests that the number of people holding meteorology degrees is significantly higher. To wit: of the 12 people in my graduating class, four are meteorologists). With such a tiny fraction of the population trained in atmospheric science generally, and severe storm meteorology specifically, it should come as no surprise that the public knows relatively little about severe weather. With the small number of meteorologists, a heavy reliance is placed upon the media and local officials to convey information.
However, while the media and local officials may get more exposure to weather information, they do not necessarily understand it any better than the rest of the general public. This leads to newspapers reporting that a “local tornado warning was issued” (only the National Weather Service issues tornado warnings officially, and causing confusion about this does not help the public interest) after a “funnel cloud on the ground” was sighted (a “funnel cloud on the ground” is more properly known as a “tornado”, but in this case it was more likely a mere “scary-looking cloud”). It leads to emergency managers sounding warning sirens when the greatest threat is heavy rain and sub-severe winds. And it leads to confusion and eventual complacency for the public.
Meteorologists have enough trouble fighting complacency as it is. The most recent data from the National Weather Service indicates that 76% of tornado warnings are false alarms. This is not because of incompetent meteorologists. It is a limitation of available observation systems (radar), of the understanding of tornadogenesis, and of the (quite reasonable) belief that it’s better to overwarn than to miss a tornado. Additionally, since tornadoes are often relatively small and short-lived events, it may be that some of these false alarms are not so, but there are no reports thus the warning remains unverified. The upshot of all of this is that it’s very easy for the public to not take warnings seriously.
I can, perhaps, understand the reason the Tippecanoe County Emergency Management Agency (TEMA) decided to sound the sirens last Saturday. A street festival was about to begin in downtown Lafayette, and many people were moseying down Main Street. The wind and rain had already begun clearing the streets before the sirens sounded, and no one seemed to be in any additional hurry when they heard the beautiful wail. It can argued that the sirens were sounded appropriately in that case, but the public mindset is that the sirens are “tornado sirens”, so sounding them for non-tornadic events (especially events that posed such a dubious threat) does a disservice to the public because it increases complacency. In this specific case, the sirens added nothing helpful, and thus should have remained silent.
Were this an isolated incident, I would not have felt compelled to write this post, but TEMA during the Mark Kirby era has been quick to sound the sirens. In my circle of meteorological friends, there are two common consequences to rainfall: 1) the Indianapolis radar goes out of service, and 2) the tornado sirens are sounded in Tippecanoe County. If I’ve associated the sirens with rainfall, surely there are others in the county who have done so as well. So who benefits from sounding the sirens so much? No one.
You may recall on Saturday that I mentioned some big things that were coming. Fortunately, you don’t have to wait long. I’m proud to announce that an idea I’ve been thinking about has finally been realized this weekend. Without further ado, the Funnel Fiasco mobile weather site. The idea behind this site is simple: the National Weather Service makes a lot of data available but it isn’t always in a mobile-friendly format. Even the NWS mobile page has some bad navigation (and more importantly, doesn’t include velocity data, which is very important to chasers). All I’ve done is to re-package the data in a way that I want to see it when I’m away from the computer.
All of the data is mirrored and hosted locally to minimize my impact on the NWS servers (and thus save taxpayer money!). The local storm reports (LSRs) are grabbed by a cron job every 10 minutes. I use the comma-separated value (CSV) files hosted on the Storm Prediction Center’s storm report website. The CSVs are parsed by a Perl script I wrote and then a static HTML page is generated. For the radar data, the images are mirrored on demand and a Perl script generates the output on the fly. The radar data piece is a fairly heavy-duty script (by my standards, at least) and so I still consider it in beta. For now, it actually runs on my server at home and not on the main funnelfiasco.com server. I plan to move it onto funnelfiasco.com (and hope it doesn’t kill my bandwidth limits) after further testing.
I have to say, I’m pretty proud of the work I’ve done, almost all in the space of a weekend. It’s nice to be able to add some useful content to my site. I hope that it will get some good use and continue to grow. As I come across data that can be easily manipulated, I’ll add it to the site. Of course, if you wonderful readers have data you’d like to see, please let me know.
People who have training or experience in following severe weather rarely are content to rely on the media for severe weather information. This isn’t to say anything against the TV and radio outlets, but we would just rather see the data for ourselves and make our own decisions. A number of software packages exist for analyzing weather data, of varying price and quality. For Linux and OS X users (and Windows users via Cygwin), perhaps the most powerful is GEMPAK, developed by the National Weather Service and made available by Unidata.
GEMPAK is basically what national centers, including the Storm Prediction Center and the National Hurricane Center currently use for data analysis and visualization. It is also a pretty old suite, written in pretty old Fortran, and kind of a bear to get installed sometimes. Unidata formerly provided pre-built binaries, but only source code is available for the 5.11.4 release. Since there seems to be an absence of step-by-step instructions, I thought I’d post my own. Of course, as soon as I post this, a public release of AWIPS II will be announced.
The first step is to prepare your environment. This basically consists of creating the appropriate user and/or directory structure. For simplicity and security reasons, I prefer not to create a separate GEMPAK user. I prefer to just build it in a directory that I have access to and then move it to opt when I’m done. If your account will be the only one using GEMPAK, you can just leave it in your home directory. For the sake of this demonstration, let’s assume we’re doing it my way. Then there’s no pre-work to do.
Next you’ll need to download the GEMPAK source code from Unidata’s website. Unidata requires registration to download the software, but it is free and they don’t harass you. While you’re waiting for the tarball to download, you’ll need to make sure you’ve got a few of the packages necessary for building GEMPAK. Most of them can be found in the yum repository, so you can install them with:
su -c "yum install gcc-gfortran libXp-devel libX11-devel xorg-x11-fonts-ISO8859-1-75dpi"
You’ll also need OpenMotif packages, but they can’t be newer that 2.3.1. This means you cannot install the packages from the RPMFusion-nonfree repository. You’ll have to grab them manually from MotifZone. There aren’t builds for recent Fedora releases on there, but the Fedora 9 RPMs work fine with Fedora 12. Since we’ve installed these RPMs, you need to make sure yum won’t try to upgrade them, so make sure you exclude “openmotif*” in /etc/yum.conf.
By now, the tarball should be downloaded. You’ll need to unpack it just like you would any other. Let’s assume you downloaded it to ~/Download, so go to the directory you want to build GEMPAK in and run:
tar xfz ~/Download/gempak_upc5.11.4.tar.gz
Now cd into the GEMPAK5.11.4 directory you just created. The first thing you’ll need to do is edit the Gemenviron.profile (if you use the Bash shell) or Gemenviorn (for C-shell). This file sets the myriad of environment variables that GEMPAK uses. Fortunately, it is sanely built, so you only need to make a few changes. Change the NAWIPS variable to point to the directory you’re building in (for example, $HOME/GEMPAK5.11.4). USE_GFORTRAN should already be set to 1, but double-check that it is and that the references to USE_G77 and USE_PGI right below it are commented out. Eventually, you’ll also need to make sure the GEMDATA and LDMDATA variables are set correctly, but that’s beyond the scope of this how-to.
After you’ve saved the Gemenviron[.profile] file, you’ll need to make sure config/Makeinc.common is correct (it probably is) and you’ll need to edit config/Makeinc.linux_gfortran (or config/Makeinc.linux64_gfortran if you’re on an x86_64 system. You can check that with `uname -i`). Change the MOTIFINC variable to “-I/usr/include/openmotif” and change X11LIBDIR to “-L/usr/lib/openmotif” (replace “lib” with “lib64″ for x86_64 systems).
There’s one more step to get things working, which appears to be a result of Fedora 12 using a newer version of autotools than the source was prepared with. You”ll need to run the following command in both the extlibs/netCDF/v3.6.2 and extlibs/JasPer/jasper directories (return to the GEMPAK5.11.4 directory when you’re done):
autoreconf --force --install --symlink
Now that that’s done, you’ll need to load the GEMPAK environment. For the Bash shell, use `. Gemenviron.profile` and for the C-shell use `source Gemenviron`. The next step is to actually build the programs. It is a lengthy process (I timed it at about 8 minutes on my system), so you might want to go get a cup of coffee or something. Since it produces a lot of output, we want to make sure we can go back and look through it if there are any problems (it took about 5 build attempts before I got these instructions to a workable state), so we’ll save the output to a file called make.out.
make >& make.out
Once that’s completed, it’s time to install the files and clean up after ourselves:
make install; make clean
If you plan to move the built GEMPAK into somewhere like /opt, now’s the time to do that (make sure you update the NAWIPS variable in Gemenviron[.profile] appropriately). I prefer to move it to /opt and then create an /opt/gempak symbolic link to the GEMPAK5.11.4 directory so that if I install a different version, I just need to change my link and everything else works the same. For ease of use, you should set your shell configuration file to call the Gemenviron[.profile] script at login if you plan to use GEMPAK frequently.
That’s all there is, it’s ready to use now.
Well, the results are in for the TS Ida forecast contest. I’m glad to say that yours truly finally won. Of course, there will be plenty of argument about the faults of the scoring equation. You’ll get over it. I don’t know who Dr. Free Beer is, but next time, try to get your forecast in the right hemisphere at least. Which brings up a good point… I think I’ll edit the game code to have a field for e-mail address (it will be hidden from the public, but available to me so that I can contact players/verify edited forecasts).
Fortunately for interests along the Gulf of Mexico, Ida has been mostly nuisance. This is not a bad way to end what has been another rather tepid hurricane season. Ida went extratropical very shortly after making landfall (much to the chagrin of my friend Kevin). I wonder if it set a record for quickest tropical to extratropical conversion. Not that Ida was all that tropical at landfall.
In other news, thanks to Perl’s Math::Trig module, I can now trivially calculate the Great Circle distances, which has long been the sticking point. At this point, all that remains to automate the scoring is some parsing and simple arithmetic. That’ll make it easier to get results out quickly. I haven’t yet decided if I should stop producing static results pages and let the CGI generate the results page on the fly, or if I should continue having separate, static pages for the results. I might go with the former in order to conserve disk space. I have no limit on cycles, so long as I don’t take down my provider’s server. We shall see. The first step is to actually write the code like I said I would two years ago.
This morning’s Area Forecast Discussion from the National Weather Service office in Romeoville (Chicago), IL is an instant classic. As such, it has been added to the hallowed halls of the Forecast Discussion Hall of Fame. Thanks to my friend Kevin for pointing it out to me.
The Community Collaborative Rain, Hail, and Snow (CoCoRaHS) project is really interesting. It is a nearly-nationwide collection of volunteers who take daily measurements of the precipitation they receive. I participate because my meteorological education has taught me that there’s always a need for more data. The side benefit is that I get to see what others around me have received in the way of falling moisture. The differences across small distances can be pretty large sometimes (although I suspect that is often due to a poor rain gauge setup), but seeing similar numbers can help you believe that you really did get that much rain.
Case in point: since Tuesday, my station has recorded 4.56″ of rain. To put that in perspective, the average rainfall for the month of May is 3.93″. On Wednesday, when I recorded 2.03″, I might not have believed it had other stations nearby not recorded very similar values. Today’s 2.35″, on the other hand, was pretty believable on it’s own. The lake that is my yard spoke volumes.
Last weekend, my wife and I hauled, mixed, and poured 3,200 pounds of concrete. Why? Because the walkway that goes from our front porch to our driveway sat lower than the ground around it, meaning when it rained, your shoes got wet. I’m very grateful we got it finished, since when we got home from a friend’s house last night, our yard was a marsh. Even now, over 12 hours after most of the rain has stopped, the ground just has nowhere to put the water.
 |
 Measuring nearly an inch of standing water in the yard. |
 Worms, worms, worms! |
As a result of all the rain, the Wabash River has gone from 6 feet to 16 feet since 8 AM Wednesday, with a forecast crest of 20 feet at 8 PM tonight. At 20 feet, Extensive flooding increases. Flood waters begin to cover Stair Road located on the southeast side of the river just off SR 225 in NE Tippecanoe County. Low portions of Barton Beach Rd is flooded. Several river residences are nearly isolated by high water. River residences near Interstate 65 are affected by high water. River Road near Wabash Valley Hospital floods. Local roads begin to flood in the Granville Bridge area. River residents become concerned.
Powered by WordPress