New Toys Means Analysis Time!
Full steam ahead - when Austin and I got back from our Thanksgiving breaks, we found our Linux workstations had arrived and been installed in our office. And thus began my endeavor of setting up, installing, compiling, and tweaking every setting imaginable in order to have a comfortable and functional development environment. Yes, even the time spent (which I do not care to admit publicly) compiling software to run a desktop CPU/memory monitor widget is incredibly important in the development process. Being able to call the machine your own is important - it becomes an extension of you as you machine code and bend data to your will.
Customization and installing of important libraries/software aside, having our workstations means we can finally do some actual data processing. I hate to say it, but my beast of a MacBook Air just doesn't cut it when it comes to interactively rendering tornado simulations. While VisIt was useful in making some cool 3D volume rendered animations using BlueWaters, what our research team is really interested in is getting to do some parcel trajectory analysis - in particular, using the VAPOR software from UCAR.
Trajectory Analysis & VAPOR
VAPOR is an awesome interactive tool for visualizing 3D data and saving images and animations, but what really caught our attention was the fact it has built in trajectory analysis functionality. As opposed to either a) writing our own trajectory code or b) using a prewritten numerics library, VAPOR has the benefit of allowing visual interactivity while placing parcel trajectory seeds, changing the domain where the trajectories will be dropped, and seeing the results quickly while rendering it with other data variables. The down side: the trajectory code in VAPOR does not track variables along the trajectory path.
Surely, though, if the trajectory code is written and already has functionality to save the paths to a file, it shouldn't be difficult to keep track of one more variable around the path, right? Well, it isn't exactly that simple, but still simple enough. Oh, and it's also all written in C++. I've never been more thankful for that one Data Structures class my Junior Year. Thankfully, the folks at UCAR were incredibly helpful in pointing me in the right direction in order to pull this off, and I was able to modify the VAPOR source code to track a variable (such as buoyancy, vorticity forcing terms, etc) along a parcel trajectory and save it to the disk for further analysis. This means we can now interactively look at regions of the storm that are interesting, draw a box, integrate some trajectories, and save them to disk for some hard number crunching on what makes this simulated storm tick! One step closer to some real-deal quantitative analysis!
Testing Modifications & Making Animations
Obviously in order to test these source code modifications to VAPOR, some sample trajectories had to be run. And naturally, I also needed to figure out a solid workflow to go from VAPOR -> animations (GIF, MP4), so might as well kill two birds with one stone. VAPOR will save out sequences of JPEGS, so I just needed something to get those sequences into a GIF or MP4. FFMPEG took care of the MP4, but contrary to what those familiar with this problem would have intuitively guessed, I did not go with ImageMagic. I discovered a branch of ImageMagic known as GraphicsMagick that supports parallelism using OpenMP, so I went with that instead.
Since I know the real reason people visit this blog is for the animations and pictures, below are a couple of loops I made using VAPOR.
Vorticity Magnitude + Unsteady Trajectories
This animation uses the total vorticity magnitude from all 3 components, where the warm browns/oranges are lower vorticity and the greens/blues are higher values of vorticity. The primary features of interest are the tornado (duh!) and the Streamwise Vorticity Current (SVC) - the river of brownish vorticity that feeds the updraft. Each one of these lines flowing through the volume gets saved to disk and saves the information of what the value of a field is along the path.###### Model Cloud + Surface Buoyancy This was just a test of VAPOR's rendering. It's not quite as nice looking as VisIt when it comes to the quality of the volume render, but it's a lot less fickle and less prone to crashing from blowing up the memory usage on Blue Waters.
Looking Ahead to a New Year
Honestly, I hadn't expected finishing up these code modifications so quickly, and really anticipated it being done sometime around the start of the New Year. Things will wind down as finals + Christmas roll around, but moving forward from here, I know the primary agenda is looking at the vorticity forcing terms (especially baroclinic generation) for different regions of the storm at different points in its life cycle. From there, I suppose we'll just see where the data takes us.
If you're interested in reading a fascinating paper that involves trajectory analyses and vorticity budgets, I really recommend checking out Dahl 2017 - really fascinating stuff!