While we redesigned our company website, we didn’t want to wait to launch it until we had migrated all of our product websites to Concrete 5.   To combine the two systems under one domain name, we leveraged Varnish as a proxy to split requests between our LAMP stack hosting Concrete 5 and our Windows server hosting DotNetNuke.    We’ve found Varnish to be a robust and yet lightweight tool for proxying, caching, and load balancing.  You can read more about how we used Varnish to host Walkshed on Amazon Web Services in this related blog post.

Another concern when migrating CMS’s is making sure that the old URLs continue to function and issue the right redirects to users and search engines.   Andrew Jennings took this project on and whipped up a URL redirection system for us using Apache’s mod_rewrite module.

• As requests come into Varnish, we first test to see if Concrete5 can respond to the URL.
• If Concrete5 isn’t managing the content for the URL, the request bounces into our redirection system that maps old URLs to new URLs using a binary hashtable and issues 301 permanent redirects to the client.   We found that this approach is faster than simply relying on Apache .htaccess files since we have several thousand legacy URLs to support.
• If the URL request is not in the mapping file, we simply forward the request to the Windows server to be served by DotNetNuke.
• If DotNetNuke returns a 404 error, we redirect the request back to Concrete 5 to respond with a 404 error so that our redirection is invisible to the user.

A final goal of the CMS migration was to improve page load times for our visitors.   Having pages that load quickly not only improves the experience for our web visitors, but also has an impact on search engine rankings.    Concrete5 suggested we setup Alternative PHP Cache (APC) to speed up the pages it is serving, which has definitely improved performance on our new pages.

We found a great WordPress plugin (which runs our blogs) that can also leverage APC called W3 Total Cache.   It provides a host of other functionality that we’re exploring including HTML, JS, and CSS minification as well as pushing design assets to Amazon’s CDN.

I always find it amusing how something as straight forward as a new website launch has so much happening behind the scenes.   To find out more about the content that went into the new Azavea website read Rachel’s related blog post.

During the optimization process, we’ve found (and been told) that the single most important optimization is to ensure memory coalescence.  I blogged about that before, so if you haven’t seen it yet, it might be worth reading before you continue on.

After maximum memory coalescence has been achieved, it is possible to focus on 2 additional metrics: occupancy and idling.

Occupancy

The occupancy metric is defined as the number of active thread groups per processor divided by the maximum number of thread groups per processor.  It’s a value in the range of 0-100%.

Occupancy is the number of thread groups (NVidia calls them ‘warps’, ATI calls them ‘wavefronts’) that are active at one time.  At any one time, some thread groups may be processing data, and some thread groups may be accessing global memory.  When some thread groups are accessing global memory, these threads are effectively stalled for hundreds of instructions, while the other thread groups continue on.

Internally, the GPU has a thread group scheduler which controls when thread groups are executed. This is extremely useful, since highly parallel operations will utilize many thread groups to perform calculations. The GPU is highly parallel, but even it has its limits. This is where the thread group scheduler comes in — it can execute some of the thread groups, while other thread groups are idle, either completed or queued. This scheduling enables some thread groups to perform memory access, while other thread groups perform calculations.

Understanding the scheduler makes it possible to ‘hide’ these global memory accesses by performing ~100 arithmetic instructions between each global memory access.  Hypothetically, if the GPU executed a kernel that accessed global memory, performed a heavy-duty calculation, then saved that result, the occupancy would probably be pretty high. The thread group scheduler would schedule a set of thread groups for accessing global memory while scheduling another set of thread groups for heavy-duty calculation. This is effectively ‘hiding’ the memory access, since the GPU can perform computation instructions while accessing memory. Interestingly, there will be a point when increases to occupancy won’t improve your performance. It is at this point when all global memory accesses are ‘hidden’ by the computation, and it becomes time to look other places for optimization.

Idling

The idling metric is defined as the amount of time the GPU is idle divided by the overall execution time of the computation.  It’s a value in the range of 0-100%.

Idling is something that we have discovered to be critical to the performance of a calculation.  The reference and training documentation instructs GPGPU developers to keep the GPU as busy as possible for as long as possible, and stops there.  By creating this metric, we were able to measure just how much this idling was affecting our computation.

As it turns out, our initial experiments showed that our GPU was idle during periods of memory transfer to and from the CPU.  This idling of the GPU was extending the overall time for computation.  Minimizing this idling through asynchronous kernel execution and memory transfer resulted in a significant and immediate performance improvement.

Coalescence, Occupancy, Idling

To summarize, the best way to optimize your GPU computations is to investigate and optimize these three steps (and in this order):

1. Memory coalescence
2. Thread group occupancy
3. GPU Idling

There are a number of smaller optimization that can be done as well, but we’ve found these to be the big 3.  Of course, you can continue this process forever, and demonstrate to your boss the law of diminishing returns.

1. thinking about your computation in a data-parallel fashion.
2. transferring working data into a local memory cache.
3. considering scrutinizing how your code performs global memory accesses.

The first item almost goes without saying.  If you are hoping to leverage a massively parallel computing device, you obviously have to break your problem or computation down into discrete units that can be operated on in parallel.

It’s the second and third point that I am going to focus on in this post, since they are the most important factors when optimizing your GPGPU code.  The reason these are the most important factors are that local memory is so much faster at reading and writing than global memory, and the memory module in modern GPUs can perform concurrent reads to sequential global memory positions for an entire thread group.

Local Memory Caching

Use of a local memory cache may seem counter-intuitive to a programmer coming from CPU land.  The best analogy would be: storing your working data in RAM instead of on disk.  While not a perfect analogy, a CPU programmer understands perfectly the ramifications of such a design decision — any data accessed from disk will be retrieved more slowly than data accessed from RAM.  Likewise for local and global memory.  Local memory is on-chip memory that is exceptionally fast.  Global memory is off-chip memory that is often used to transfer data to/from the host (often the CPU).  I’m talking about a 100x speed difference when using local memory instead of global memory.

In addition to the differences in global and local memory, the memory bandwidth to/from the graphics card (which contains its own memory and processors) and the motherboard (which contains RAM and one or more CPUs) is another bottleneck.  Data transfer rates across the PCI Express 2.0 bus are about 8 GB/s.  Data transfer rates in the graphics card are around 141 GB/s.  So not only is the place in which you store your working data important, but also when and how you transfer that data to/from the GPU device itself.

Sequential Global Memory a.k.a. Coalescence

And “sequential global memory positions”? What is that?  Inside a GPGPU kernel, when accessing a portion of global memory, all threads in that group (NVidia calls them ‘warps’, and ATI calls them ‘wavefronts’) access a bank of memory at one time.  For example, if there are 16 threads executing with the same kernel, 16 sequential positions in global memory (1 position per thread) can be accessed in the same time that it would take 1 thread to read 1 position in memory.  If all memory accesses are performed this way, performance can speed up by a factor of 16 (in the memory access code).

That’s a wonderful way to speed up data-intensive operations, especially when one is working with raster data, and a given block of cells is accessed multiple times.  It is in this scenario that our research has recently landed us.

Another thing worth noting is that coalescence concept applies to global memory on the GPU only — local memory does not suffer the same performance hit, so does not need to take advantage of this technique.  But global memory access on the GPU takes about 100x as many instructions as local memory access.  This means that if you have coalesced global memory access, you are saving hundreds of instructions per thread.  This starts to add up when you consider that processing a raster may require hundreds or thousands of threads.

Armed with this knowledge, parallel algorithm implementations begin to have similar structures with regards to memory access.  The resulting code can be highly complex, though, and it’s not trivial to debug, but some new tools from NVidia and ATI are enabling developers to profile and visualize the work performed by the GPU. In my next post, I’ll discuss latency and occupancy, two metrics that one can use to help optimize GPU kernels.

One of the reasons that GPGPU is so promising is the increasing number of processing cores available on affordable graphics cards.  This increases the computation capacity by leveraging many processors running in parallel. What’s interesting is that this technique is not new.  Timothy Mattson, blogging at Intel, has been doing this since the mid 80′s.  The Library of Congress contains a book on parallel computing structures and algorithms, dating back to 1969.

As we delve deeper into our work improving Map Algebra operations, important differences in algorithm approaches and implementations become apparent: not all parallel architectures are the same.  One might be tempted to think that when switching from the single-threaded CPU logic to multithreaded/parallel logic that there would be one model of parallel computing that is universal.  This is definitely not the case.

Three of the most popular types of parallel computing today are:

• Shared-memory Multi-Processors (SMP)
• Distributed-memory Massive Parallel Processors (MPP)
• Cluster computing

Each type of parallel computing has its benefits and drawbacks.  It really just depends what kind of computing you need to do. I’ll describe these common computing types in detail, starting with the ‘traditional’ CPU model.

General Purpose

The ‘traditional’ processors used in many computers up until a few years ago were single core processors, called the Central Processing Unit (CPU).  The CPU was able to access a large, general-purpose memory bank, called Random Access Memory (RAM).

Simplified CPU Architecture

In contemporary computers, the CPU often contains more than one core, making CPU’s capable of more than one instruction at a time.  In addition to superscalar instruction processing, this makes modern CPUs much faster than their single core, scalar predecessors.

Shared-memory Multiprocessors

An SMP architecture is probably the one parallel computing architecture that is most like the general purpose architecture with which we are familiar. SMP are a set of processors that all have their own local memory.  These memory banks are shared within a thread group, but not between more than one thread group.  However, each processor also has access to a global memory bank, which is shared between all processors.

Simplified Shared-memory Multiprocessor Architecture

This is the parallel architecture that NVidia and AMD/ATI both use in their GPUs.  Likewise, it’s also the model enforced in the OpenCL specification.

Distributed-memory Massive Parallel Processors

The most complicated and flexible architecture type is MPP.  MPP systems isolate memory and processors together, and as such, have no common or shared memory.  Each processor has a dedicated block of local memory, and communicates with other processors via a bus or network.  By varying the number of processors each processor is connected to, different types of MPP systems can be created.  For example:

• Linear array: if the processors were arranged in a line, each processor is connected to 2 neighboring processors
  

  Simplified Linear Array Architecture

• Linear ring: if the processors were arranged in a circle, each processor is connected to 2 neighboring processors (a linear array, with the ends connected)
• Mesh: if the processors were arranged in a grid, each processor is connected to up to 4 neighbors (3 on the edges, and 2 in the corners)
  

  Simplified Mesh Architecture

• Tree: if the processors were arranged in a hierarchical manner, with each processor connected to the processor above it, and two processors below it.
• Pyramid: if the processors were arranged similar to a tree, but in three dimensions, with each processor connecting to four processors below it.
  

  Simplified Pyramid Architecture

• Cube: if the processors were arranged similar to a mesh, but in three dimensions, with each processor connected to up to 6 neighbors.
• Hypercube: if the processors were arranged similar to a cube, but in four dimensions, with each processor connected to up to 8 neighbors.

As you can see, the processors in MPP systems can proliferate quite rapidly with more complex processor network topologies.   We haven’t worked with any MPP systems for our GPU research, so I’ll let you ponder that while I return to the GPU architecture.

GPU Memory – Not Your Father’s RAM

As I mentioned above, GPUs and OpenCL implementations are based on the SMP architecture.  As such, GPUs have multiple types of memory, with different implications for each type.

• Global memory: this is often the big number on the graphics card packaging.  512 MB DDR, etc.  This is the amount of global memory that is available to the GPU processors.  This memory is essentially used as a fast cache to the motherboard RAM, since it’s used to transfer raw data to the GPU for processing, and storing computation results prior to reading out back to motherboard RAM.
• Local shared memory: this is a much smaller bank of memory that is extremely fast.  On the hardware that we’re using, it’s limited to 16KB. With some smart memory management, this local memory can really speed up computations, since the instruction cost of accessing this memory is 1% of that required to access global memory.  Also, this memory is shared between all threads in a work-group.
• Private thread memory: this is an extremely small bank of memory that can be used within each thread for variables and temporary storage during your computation. Interestingly, in the NVidia implementation, this uses registers for a certain amount, then starts using global memory when registers are exhausted.

The differences in memory types are probably the first thing a general purpose GPU programmer will run into. Another thing to keep in mind is the method by which the GPU achieves such high throughput, and that’s thread parallelism.

Single Instruction Multiple Threads

In OpenCL, each parallel code path executes one kernel.  The best possible outcome (in regards to thread synchronicity) is when each kernel executes the exact same instructions as all other threads.  With each thread managing a different nugget of data, this results in extremely fast execution.  However, if the kernel code diverges or branches, there is a performance penalty: that section of your code will execute serially (think 16x to 32x slower).

NVidia implements this architecture, and has called it Single Instruction Multiple Threads (SIMT). It’s kind of like line-dancing for threads.  All threads that execute the same instructions can perform together.  If a thread diverges or branches, then the line-dance is broken, and each thread processes a divergent section one after another.  What’s kind of cool, though, is that the threads will join back up after diverging, and continue on together.

Wrapping it up

With a solid understanding of how the GPU operates in addition to the limitations of memory and threading, it’s relatively easy to start computing on the GPU.  Many common operations are easily parallelizable, such as sorting and basic mathematical operations.  When you start performing serious number crunching, or if you are porting a beefy algorithm from serial CPU code, that’s when the real fun begins.

That means that NVidia is pushing their GPGPU API, which is named Compute Unified Device Architecture,” or CUDA.  Their rival, AMD/ATI, is pushing Stream. Stream incorporates BrookGPU, a compiler and data-parallel language developed at Stanford University, which predates CUDA.

NVidia & CUDA, ATI & Stream, or OpenCL

Both of these vendor APIs are proprietary, and run on each vendor’s specific hardware.  This makes sense if a developer can control what hardware computations will be using. Realistically, a developer rarely has such control. So what are the options? At the current time, there are only a couple:  OpenCL and Microsoft’s DirectCompute technology.  Microsoft’s technology is limited to Windows Vista and Windows 7, though, so we are focusing on OpenCL.

OpenCL is the Open Computing Language, a language that extends the C99 standard (a modern dialect of the C programming language) and compiles into device-specific binaries. OpenCL was originally developed by Apple, and handed over to the Khronos Group. The OpenCL standard was ratified by the consortium in December of 2008.  The Khronos Group consortium includes all the major players in the field, including NVidia, AMD/ATI, Apple, and Intel.  The list is much more extensive, but those are the four to be happy about.  Intel doesn’t support OpenCL in their multicore CPUs, but I’m optimistic that they will release an OpenCL API to leverage CPU cores as well as GPU cores as computing devices.

OpenCL was created to address the need for speed in current desktop systems that contain GPU processors.  The language was created to address computing on heterogeneous systems, which, when you think about it, can include many other types of computing devices.  If OpenCL is adopted by Android, then you could optimize code to run on Android devices, too. While this may not be the fastest approach, it would potentially let you distribute work among devices.

One caveat to heterogeneous systems, though: OpenCL kernels that are written and optimized for one hardware platform probably won’t perform the same as on another hardware platform.  While OpenCL enables developers to write code that can run on multiple hardware devices, the hardware implementations may vary.  For example, the number of processor cores, and thus the number of parallel threads may vary widely.

If you can’t tell already, we are sold on the promise of OpenCL for GPGPU.  The language is easy to use (if you already know C), and it supports the two biggest players in the GPU market, NVidia and AMD/ATI.  We are hoping that Intel releases their OpenCL drivers for CPUs, too, so that we can squeeze out the last drip of computing power for our computations.

At first, it may sound like multi-threading, and in a way it is.  What’s key, though, is that the GPU doesn’t just multi-thread, it’s synchonized, lock stepped multi-threading.   It’s called Single Instruction, Multiple Data, or SIMD in Flynn’s Taxonomy (NVidia’s hardware uses a variant called Single Instruction, Multiple Threads, or SIMT).  This refers to the control flow in each thread on the GPU — to maximize performance, it’s important to get all threads running through the same logic at the same time.  In practice, some threads will eventually branch, and keeping the branching to a minimum is critical.

When we have processing tasks that can be highly discrete, the SIMT nature of the GPU enables computations to really fly when using GPGPU.  Structuring computations in this fashion will result in operations that are highly parallelized.  Coincidentally, they will also be easily distributed to other computation engines.  But unlike other distributed computing methods, GPGPU is tightly coupled, and has very low latency — you get immediate results.

To facilitate all of above, GPGPU requires a video card that supports programmability.  While the major GPU manufacturers have released proprietary GPGPU languages — for example is NVidia’s CUDA framework — a cross-platform, device-independent alternative, called OpenCL, has recently become sufficiently robust that we can begin to use it for implementing GPGPU processing.  While originally developed by Apple, OpenCL is now overseen by a non-profit organization, the Khronos Group.

If you’ve got a GPU on hand, it’s quite likely that there is an OpenCL API available in your programming language of choice.  Here’s a short list from the Khronos Group’s website:

• Python
• Ruby
• C
• C++
• C#
• VB.Net
• Scheme

By the way, Khronos just released the spec for OpenCL 1.1 on June 14th, 2010.

GPGPU for GIS

Our interest in GPGPU is motivated by our desire to speed up complicated raster math calculations, in particular those that would enable us to make more sophisticated geoprocessing available on web and mobile platforms.  Our vision is to make an order of magnitude or better improvements in geospatial data processing and thereby make web-based analysis tools more responsive and compelling.  To support our research we applied for and were awarded a National Science Foundation (NSF) Small Business Innovation Research (SBIR) grant to benchmark some traditional GIS operations against  GPU-accelerated versions of the same operations.  Our objective is to improve these operations by about 20x, and it looks promising.

We’re sampling the wide array of Map Algebra operations that are in standard GIS toolkits, focusing on a couple examples of each of the following types of operations: local, focal, zonal, and global.  Some of these types of operations are easily parallelized, such as local and focal operations.  The other operations require a fair amount of algorithm wrangling before they show any improvement on the GPU’s parallel architecture.

Our research is ongoing, so it’s still a bit too early to tell, but we’re excited to already see some impressive performance improvements.

GPGPU Lessons

Migrating our chosen Map Algebra operations to the GPU was trivial in some cases, but quite challenging in others.  For example, local Map Algebra operations are quite easy to parallelize.  Each raster cell is compared to another raster cell in the same location.  This requires very little extra memory and few intermediate steps.

Focal (or “neighborhood”) operations are not simple, particularly for large neighborhoods, but with some intelligent partitioning, it’s relatively easy to work with different sections of the rasters.  This requires some intermediate buffers, but performs well using local memory on the GPU.

Zonal operations summarize the cells in one raster data set using zones identified in a second one.  These operations require a couple scans across a raster, and a few intermediate stages — that one was complicated.

What’s crazy difficult, though, are the global operations.  These operations are challenging because they operate on the entire dataset, with one cell on one side of the raster potentially affecting a cell on the other side of the raster. Examples of global operations include Euclidean distance, cost-weighted distance, viewshed analysis and others.  These operations are non-trivial to convert to GPU processing in a performant way, but it is definitely possible.

Computing power continues to grow at an exponential rate, and is well characterized by Moore’s Law (if you are looking for a graph more recent than 1965, try Wikipedia).  This means that computing power is moving in many directions.  The rise of laptops, notebooks, tablets, and smartphones are a testament to the increasing computing power of microprocessors.  They are getting faster, smaller, lighter, more power efficient, and sprouting more cores.

Despite this accelerating computing power, however, on some of our projects, we’ve seen how many heavy-duty analytical computing tasks remain too costly (in terms of computing time) to be run on the web with more than a small number of users.  However, by distributing the computation across multiple processors and machines, we have found it is possible to improve both the scalability and speed of some geographic data processing tasks.  For one such task, a weighted raster overlay operationg, we have been able to accelerate the process enough to make a scalable web application possible.  Azavea’s DecisionTree framework, developed with support from an SBIR grant from the US Department of Agriculture.

With this experience developing distributing geoprocessing algorithms, we have recently been taking a look at technologies that will enable us to make similar types of performance and scalability improvements.  One technology that we believe has great promise for bringing these processes to the web is General Purpose Computing on the Graphics Processing Unit (GPGPU).

GPGPU leverages the microprocessors that power many modern graphics cards.  NVidia and ATI are the largest players in the high performance video adapter field, and they both have GPU computing libraries that run on their video adapter hardware.

GPU’s are accelerating everything.

GPU’s are powerful for general purpose computing not just because of their clock speed, but because there are just so many multiprocessors on today’s GPU graphics cards.  While a quad-core CPU is a high-end processor for most servers, today’s high-end graphics cards have 100, 200 and 500 or more cores and are capable of gigaFLOPS double precision processing power (NVidia, ATI, respectively).  And these numbers are doing nothing but going up.

A few ways of comparing just what that means:

• a handheld calculator runs at about 10 FLOPS (not giga-, just plain FLOPS, one billionth of a gigaFLOP).
• by the time you blink your eye, 154 gigaFLOPS have occurred on the NVidia Tesla C2070.
• by the time a hummingbird flaps it’s wings, 10.3 gigaFLOPS have occurred on the same card.
• by the time one FLOP has occurred on the same card, your voice has only traveled through 0.64 μm of air (human hair ranges from 17-181 μm thick)

In addition to processors and processing speed, GPU cards have fast, specialized memory access.  They have a limited amount of local memory, but if you can figue out a way to use it efficiently, your memory access is on the order of 100x faster than conventional memory.

The combination of more processors and faster memory means that if you can discretize or parallelize the type of work that you want to perform, you can get radical speed improvements.

GIS on the GPU.

That’s all well and good, but how can GPGPU be used for GIS?  We are not the only ones thinking about this, but the answer depends on what kind of analysis you want to do.  We have been focusing our research on a few types of MapAlgebra operations, and our preliminary investigations have shown that all types of MapAlgebra operations can benefit from processing on the GPU.  In addition, we believe substantial improvements can be made in some types of vector processing with a few likely candidates would be:

• Vector-to-raster and raster-to-vector conversion
• Network analysis
• Network routing
• Transformations of geometric collections

All of these optimizations have the potential of reducing the computing time for heavy duty GIS operations from hours to minutes, and therefore minutes to seconds.  With that kind of speedup, the “attention threshold” of the web can be achieved.  It now becomes possible to run more complex GIS tasks in a web environment, bringing more computing power to the masses.

These changes won’t change the world right away, but it will make GIS analysis more interactive, responsive, and efficient.  Just imagine if you could complete any given task in your day in 1/10th the time (think Dash, from the Incredibles).

The first hurdle to be overcome was that the vast majority of the Centennial Expo’s buildings (and some of the streets) don’t exist anymore! The Expo took place in a swath of Philly’s Fairmount Park, most of which has turned back into trails and fields over the years.  Some of the buildings were torn down just after the Expo closed; some of them still exist, but in other places. Only a very few buildings and landmarks still occupy the same space they did back in 1876. But do not despair for there was a map! Included in the Free Library’s records was a map of the entire fair, complete with all of the buildings and roads built for the Expo, along with neat things like fountains and plazas. Dana Bauer, one of Azavea’s employees and a geo-referencing expert, took charge of the map and managed to line up enough of the old landmarks with existing geography to give us very accurate coordinates for all of the Centennial Expo’s old buildings! Hooray!

So now we have coordinates, but we need to be able to tie those coordinates to the image records in our system. Here the data was slightly uncooperative. Many of the image records had a building mentioned in some fashion and in one field or another. The challenge here was that the text in the record didn’t always match the official name of the building from the map. For example: the Main Exhibit Hall was mentioned in records as Main Exhibition Building, Main Hall, Main Bldg and several other permutations. We spent some time figuring out around 20 aliases for some of the more popular buildings in the collection.

The last step was to build a parsing-and-geocoding module to find the building references in the record data, match them up with the coordinates we found and add that information to our database. Easy right? Not so fast. All 150-some coordinate pairs and their building text keys needed to be accessible somehow to our data importer. We thought for a while about how best to do that. 150 entries isn’t a huge list, but it’s not short either. We didn’t want to have to mess with it at all once we set something up. This list also wasn’t likely to change over time, so the list didn’t need to be very accessible or easily editable by people. However, we were also going to need it again to return to the Free Library in some format or another at the end of the project. The coordinates were in an Excel spreadsheet by this point, but we didn’t want to deal with the overhead of accessing it directly. We wound up creating a data dictionary inside our importer; kind of a mini geocoder table just for this swath of Fairmont Park circa 1876. We left the parent Excel spreadsheet alone as both a backup archive and the basis for the document we’ll be returning to the Free Library.

While looking though the data for building aliases, we also noted the fields where these names were found. So all we had to do was write a small function to loop through these fields, do some text matching on our data dictionary and add the coordinates to the record in our system. Out of over 1500 images, we wound up geocoding over 90% using this method, and most of the rest simply didn’t have a building reference to find. The entire import, images and all, took under 10 minutes. Not bad at all!

One of the problems opportunities that I observed was that as coffee was brewed and consumed in the office (about 6 brews a day), there would often be an unlucky staffer who picked up the (opaque) coffee pot to find it empty.  I don’t personally drink coffee, so I was unaware of how much anticipation one would have when approaching the pot.  Not knowing how much coffee was in there, and worrying if the mug you pour may be half empty or half full.

I slowly set to work in my free time to solve this conundrum.  To me, it seemed like an individual would want to know if there was coffee in the coffee pot before approaching the coffee maker (whom some of us address reverently as Zojirushi-san).  This could be 1) a web page, 2) a desktop app, or 3) an IRC (not IIRC) bot.

I drew up some schematics, took some measurements, and retreated to my home lab to build an Arduino based, web-enabled measurement system tailored for the coffee pot. I used an Arduino Diecimila, an Ethernet Shield, a couple piezoelectric sensors, a 3 color LED, a couple buttons, and an awesome hand-crafted wooden base.

A short while later, I had a working prototype ready for testing. This device now sits in Azavea’s kitchen, measuring the weight of the coffee maker, and reporting the measurements to pachube.  After doing some internal evaluation, the name ‘Caféduino’ stuck, and I developed a couple methods of viewing the coffee pot status.

1. Direct web access
   

   The web page generated by the Caféduino

   Using this method, it’s possible to directly address the Caféduino.  This gives one direct access to the measurement values, but is more useful for other applications that are polling the data frequently.

2. Caféduino Notification
   

   The system tray notification app.

   Using this method, the Caféduino is polled continuously, and the tiny coffee mug in the system tray is updated as the coffee level changes.  This is the most aggressive method of monitoring the Caféduino which, mysteriously, is the most comforting for users.

   

   Visualizing the Caféduino history.

   When the coffee mug is clicked, the history of the Caféduino is charted in the window.  What you are seeing is a Google visualization applet that is consuming the historical data, stored on http://www.pachube.com/.

3. IRC bot integration
   

   A sample IRC conversation with the IRC bot.

   Lastly, the most interactive method of polling the Caféduino is through our internal IRC channel. The above screenshot is the conversation that I initiated with the IRC bot, and its response.  It has reassured me that there is indeed, 77.78% of a pot of coffee left.

Now our staff can check in on the coffee pot, to insure that their next visit to the kitchen will be without disappointment.  While this system works well for monitoring the coffee level, the next steps may be more involved – building a machine to automatically brew coffee.

MassDOT has been making steady progress opening transportation data to developers over the past few months. In September of 2009, they first released 2 full days worth of passenger data, and challenged the developer community to play with it to develop a visualization and application that used that data. Then in November of 2009, they hosted a developer conference, announced the winners of their first challenge, and announced the release of a real-time XML feed. They kept that ball rolling in February 2010 with a Hackathon at MIT with the Center for Future Civic Media, and then the announcement of the Real Time Challenge.

Screenshot of BusMinder in action.

My response to the real time challenge: BusMinder (http://sandbox.azavea.com/mbta/).  BusMinder is an experiment, designed to enable users to create bus reminders (‘busminders’) for their favorite bus stop(s).  Users walk through the process of:

1. Selecting a bus stop
2. Selecting a reminder type (sms or email)
3. Selecting a time window

It’s that simple to get started. The application will save those settings and remind the user when an MBTA vehicle is approaching that stop, and how far away it is in minutes.  Once a user registers, they can set up multiple reminders (commuting to work and commuting to home, for example).

I introduce BusMinder as an experiment because MassDOT has published this real time XML data feed on an ‘trial’ basis. Currently, only 5 bus lines are supported, and it’s understood that the data is experimental.  In fact, one of the bullet points for developers working with MassDOT data is “Expect change”.  My hope is that this application is found to be useful, and it helps MassDOT release more of their real time transit information.

I also want to give a shout out to Robert Cheetham, for Azavea’s generous Research program.  I was able to shift around my projects a bit and take on this challenge under the auspices of my independent research.  Thank you, Robert.

Ok, ok, enough already!  Go to http://sandbox.azavea.com/mbta/ and start playing!