Photo on film by Kelsea De Filippis
https://www.kelseadphotography.com
The beach is a fascinating place for me. In Oregon, the coastline is comprised of long, wide stretches of fine sand bookended by misty, basaltic headlands topped with windswept trees. It’s a wild place where tall cliffs are battered yearly by winter waves standing taller than 20 feet. In the summer, surfers and beachgoers alike flock to those same headlands for shelter from the constant, driving northerly wind.
When I first started surfing, I was around 12 years old. Dragging my board into that feral ocean felt like stepping into a mosh pit. On the “inside”, the place where broken waves roll towards the beach, objects like small surfers are tossed about with abandon. Strong rip currents tug and push and coerce you in directions that you’re not interested in going.
All in all, a pretty intense spot without an easily discernible pattern. However, as you gain experience in that arena, you begin to notice things. Swell typically moves from deep water to shallow, where eventually friction on the bottom of the wave slows it enough for the wave to “trip” over itself, tumbling in a powerful, foamy white bore towards the beach. That’s generally the first wave a surfer ever catches when they’re learning to stand on a surfboard.
https://www.coastalwiki.org/wiki/Nearshore_sandbars
When the turbulent foam ball runs all the way from the ocean up onto the beach and then retreats once more, it’s called swash. This action is a vital mechanism which helps to shape the coast itself. As waves move up and down the beach over and over, sediment is shoved about, destroying and forming new sandbars, eroding cliff sides, or rolling rocks around.
In my case, the swash zone provided an unexpected opportunity to marry the beach and software. Last March I reached out to a coastal engineer in OSU’s College of Earth, Atmospheric, and Oceanic Sciences (CEOAS). At the time, it felt unlikely that a someone studying the nearshore environment would need a computer science student such as myself. Turns out, they did have a project for me to work on.
A number of years back, a group of researchers developed a program called MatPIV using the MATLAB programming language. The goal of the program is to conduct a technique called Particle Image Velocimetry (PIV). The researcher at CEOAS uses this script to analyze footage of swash as it races up the beach and back down again. From the resulting data, they can determine the speed of the wave.
MatPIV is a wonderful piece of software for this particular application but it’s terribly slow. To process a pair of images measuring 2048 x 3072 pixels, MatPIV runs for 14 to 16 seconds. 15 minutes of footage running at 40 frames per second results in 36,000 frames. To process this many frames using MatPIV could take a little over 6 days!
As any aspiring developer knows, computational cost is an important part of building robust software. To address this issue, I was assigned the task of porting this program from MATLAB into a different, more nifty scientific language called Julia.
Right off the bat, things got tricky. I had never touched either of the languages, so I needed to spend some time familiarizing myself with the ins and outs of each in turn. As I picked apart the syntax, I began to rewrite the 1000+ line MatPIV into what I call (just in my head) JuliaPIV. Some of the time I got lucky. Many segments of code had a very similar implementation in Julia. Oftentimes, I had to find new ways of doing the same thing as MatPIV. Some particularly tricky sections come to mind: interpolating data, running Fast Fourier Transforms (FFT), discovering multiple maximum values in a matrix, and determining the median of a set of complex numbers.
As I gained knowledge and understanding of Julia and the PIV algorithm, I began to find ways to optimize the original code and cut out less than useful pieces. Although I was often stuck, the pleasure of making breakthroughs, learning, and working on a piece of software meant to be used in my favorite biome of all time made it all quite rewarding.
In the end I’m pleased to say that JuliaPIV typically benchmarks at 5-7 seconds per frame pair. A gain of more than two times as fast as the original program.
For next steps, we hope to bring the code over to the GPU side of things. CUDA has introduced a real learning curve, but after my success with the CPU version of JuliaPIV, I feel certain that I can find my way to a solution.
Keep an eye out for my next blog post,
Robin
