Weeks 9 & 10

These weeks I made major progress in writing a reset button that works for all three plots. One minor but finicky problem with the plots before was that you could zoom in or out as far as you wanted, easily getting “lost” and unable to find your original data again.

The reset button brings the user back to the plot’s initial view. It also animates the trip from point A to point B so that the user can avoid being suddenly disoriented by an entirely new view of the graph, if they either weren’t sure of their orientation before or didn’t know what the button did.

The biggest challenge wasn’t writing the button itself, but making a JavaFX button that was able to call a method in JavaScript. After a lot of reading and learning about how Java and JavaScript can be persuaded to interact, I ended up using the call() method to call a specific function inside of a script that is already running.

The problem that took me the most time to solve turned out to be that I was trying to call a function that was nested inside of another function, and was therefore invisible to Java’s call(). It became necessary to create a third function besides draw() and update() that could call update’s nested reset() function.

The Reset button is now functional on all plots and is merged with Topsoil’s main branch.

Advertisements

Weeks 7 & 8

Once I was more comfortable with the code that made up the evolution plot, I got started on my first major project with the graph. One major flaw with the plot as it stands is that most plotted ellipses are very small, and the plot has to be very zoomed in before they become visible. Once the plot is at at such a small scale, the isochron and activity ratio lines aren’t visible anymore.

Ideally, as the user enlarges the graph, the density of visible lines will stay the same, more drawing as you zoom in, and then disappearing as you zoom out again. I could have spent a lot of time up front refining a system to keep a steady ratio that had the data most useful to geologists, but that was a bit more difficult to research, especially when I wasn’t sure how I’d make it work in the first place. Instead I drew up a proof of concept that can later be refined into something permanently useful.

Arbitrarily, I decided that more lines would be drawn every time the graph became four times larger. Naturally, the new lines were undrawn each time the graph decreased to a quarter of its previous size.

The graphs were redrawn like this: one new line placed exactly between every two adjacent lines. It didn’t create the perfect ratio, things still fell apart if you zoomed in too closely, but it was much more useful than before.

Until I hear back from a geologist about the meaning of the graph’s lines and which lines would be most useful to reveal as you zoom in, this is where my experiment with the graph will stall out. Nonetheless, it was a fun experiment, and through the process I became truly comfortable with the update pattern of a graph that redraws itself live.

 

Weeks 5 & 6

Once I understood the math itself in better, closer detail, I could begin adding comments about which segments did what. Hopefully those details will make the job of the student who follows me even easier.

While combing through the code, I came across two details that immediately struck me as odd.

First, I came across four functions an a dictionary that were never used or even referenced anywhere in the rest of the project. The dictionary, plot.initialProperties, made a weird kind of sense. The earlier bug with the ellipses not displaying had been because the evolution plot hadn’t been fed the initial values it needed from an outside properties panel like the other plots were. It’s possible that initialProperties was a new dictionary that’d been halfway written to fix this problem, then forgotten about. It was a fairly easy decision to discard it.

The functions I was more hesitant to just delete, since I was unsure if they’d been intended to be used for extra functionality later on. These functions were “neg,” “mean,” “lineTo,” and “close,” all written specifically to replace either the matlab or line calculation functionality that JavaScript lacked. Those functions remain in the code, though I commented them with “unused” for easy removal later if they’re not needed.

The last thing I noticed about the code was one puzzling line:

if data.length < 0 {

//adjust the ratio and initial zoom of the plot

}

When this code was active it would squash or stretch the plot’s initial view to fit the entered data points. This means that the evolution plot’s underlying grid would be warped differently depending on what data had been entered, and that it would initialize to a zoomed view. Since the evolution plot is intended to open at the same zoom level and have the same appearance no matter what data it’s showing, this undesirable feature must have been purposefully rendered inert, though it’s puzzling why it wasn’t commented out or simply removed instead.

Week six was unfortunately mostly unproductive for Topsoil, since I spent it at the Grace Hopper Celebration, an annual women in computing conference and, recently, the largest of its kind in the world. It was an incredible experience, and hopefully I will be able to go again next year.

 

Weeks 3 & 4

Once I understood the flow of Topsoil’s JavaScript, the question of rewriting the code that generated the plots came up immediately.

My first reaction was hesitance, since I was unsure how durable the nest of code and math would be in the face of being ripped up and pieced back together. However, the more time I spent in the thicket of experimentation with the plots, the more confident I was that at the very least, the code could be made much more friendly and approachable for new students who will take over after I leave.

My first move to this end was refactoring how the ellipses were calculated. It had come up the previous semester that the graph could slow down and stall out if it was zoomed too frequently while too many ellipses were loaded. This was because the ellipses were recalculated from scratch every time the graph was zoomed in or out. My predecessor had mentioned moving that code up one level, so that the ellipses were only calculated once, and that single shape could be redrawn on zoom like would normally be intended.

This improvement did seem to help the evolution plot’s performance, and it made me question another aspect of the evolution plot’s design. The activity ratios and isochrons, AKA the blue and red lines of the evolution plot, are also recalculated every time the plot is zoomed. This is a process that involves an elaborate amount of math, and I wonder if that too couldn’t be brought up a level, so that the lines are only drawn once and then zoomed with the rest of the graph.

The real focus of these weeks was understanding the math that drew the isochrons and activity ratios from beginning to end. I understood what they represented in theory, but in practice I wanted to be able to follow what the formulas meant. I began this by starting where hard numbers were dropped into a couple of arrays at the very beginning, and then tracing them through the layers and layers of math until they came out the other side, ready to be plotted. This let me understand what data types each function took in and put out, how they connected to each other, and what would be affected if one part was changed.

Though not much tangible code was written, it was an important two weeks for coming to understand what I was working with and how I could come to make it better.

 

Topsoil – Weeks 1 & 2

Working on Topsoil for the third semester in a row, I have begun to find a specialization within the project. Over the summer of 2016 I had the chance to work with D3.js, a JavaScript library that lets users gracefully turn data into flexible SVG graphs.

D3.js also happens to be the library used in Topsoil, the open-source software for geochronologists I’ve been helping to develop with my student research team, CIRDLES. With this happy coincidence falling into place, I spent the fall of 2016 understanding, debugging, and refining the D3 in Topsoil.

My first two weeks on the job, I faced down a handful of small projects.

screen-shot-2016-12-09-at-1-50-00-pm
the evolution plot

First, Topsoil’s evolution plot is based off a Matlab file that contains comments and approaches to the math that weren’t in Topsoil’s version. It was helpful to dive back into the original document so that I could understand which parts of the current code were written by my predecessor on Topsoil, and which parts were written by geologists before Topsoil ever existed. I found a pretty clear line between the easier-to-follow D3 that drew the graph and the thicket of math that makes the graph possible in the first place. Once the code could be understood in two parts like that, it was fairly simple to find the source of the first bug that I needed to hunt down and fix.

Topsoil’s evolution plot is designed to display a series points that are the most likely age of a geological sample, and then draw ellipses around those dots that represent the uncertainty of that calculation. When I came to it at the beginning of the semester, my first task was to hunt down a bug that was causing these ellipses to not display.

Once I understood both the JavaScript that drew these plots and the Java that connected them to the rest of the project, the problem became obvious. Where the other two plots were ties to properties in Java that were then imported in, the evolution plot didn’t have one. Since these crucial variables weren’t being imported correctly, the ellipses were attempting to calculate themselves off of values that weren’t there, and so they never appeared at all.

Getting used to the code and tracking down the problem was the hard part. Noticing which classes the other plots had that evolution didn’t was easy in comparison, and soon the problem was fixed.