A Plotter for Systems of Linear Differential Equations



Yes, the title is rather self-explanatory. This is a program made in Processing, a language that takes otherwise plain Java and makes it easily visual. It was made by Brianna Reilly for a final project in Mr. Bonanomi's LADE (Linear Algebra and Differential Equations) class.
Inspired by this resource written by Darryl Nester, this project was an experiment in learning how computers approximate and display systems of linear differential equations. This project aimed to be illustrative of how a source point reacted within a system, not just through a still line tracing its movement, but an animation of the movement itself through the field. It also aimed to be something pretty to look at, as the author of the program really saw a beauty in the structure of these fields, and wanted to share that with others.


Controls:



Regarding the text boxes: they can be a little finicky. Pressing backspace, enter, or tab will erase the contents of the box. Due to temporary limitations to make the box otherwise a lot more usable, a user cannot enter the same character twice without moving onto a different box first. For example, to type "11", type the first 1, click outside the text box, and then enter the textbox again to type the second 1. Sorry for this inconvenience, but a workaround for this will be added in the future, likely prioritized.

Process:

Once the main goal of the project was established, the first thing to be figured out was which method of differential approximation was going to be used to calculate the points' positions. There are many methods that do this, with varying degrees of accuracy, performance speed, and coding difficulty. The simplest of these is Euler's method, and this was the one decided on in the end. While the least accurate of the many, it was the easiest to implement, and is accurate enough at a "step size" of .1 for any system of equations that can be achieved with this program so far.
Euler's method, when applied to just one differential equation, can be summarized as such:


In words, this means that each time the method is stepped through, the new y value is just the previous y plus the solution of the differential equation of that y for that step size. While maybe a bit complex when explained and not shown, once figured out it is by far the easiest way to get the next step value in a differential equation. Note, this explanation is just for one equation, but can easily be adapted to a system. Instead of one of the coordinate values being the step, both x and y have their own equations that take their and their partner's prior values into account, and the step size is only multiplied by the final solution to decrease how far the point gets before calculating again what the new values should be. This is why a smaller step size is important to accuracy. For example, for a step size of .1, every step of 1, the equation is calculated 10 times. This is also why it slows down so much.
There are many other methods that can do what Euler's method does. This category of methods are referred to in general as "Runge-Kutta" methods. The first few of these that were defined with this specific purpose were developed by C. Runge and M. W. Kutta, which is where the name comes from. Euler's method, however, was developed long before there was a category for it. The other Runge-Kutta methods are further advanced, more accurate and faster, but were not implemented into the main program on display on this page. Future builds of the program may add these more advanced methods, and let users choose between which method they want to use in the control menu.
Speaking of future builds and current limitations, right now this program can only solve linear systems of differential equations. It cannot take in, for example, x' = sin(x) + y² as one of its equations. Solving for nonlinear systems adds a lot of complexity to the programming, and more time would need to be spent on that portion of the program in the future. Hopefully it will get added in time, as being able to create nonlinear system structures would really help to prove the secondary goal of this project, which is to show how pretty these systems can be once simulated.
Any further additions would be aesthetic in nature, such a choosing a color palette for the placed points, or choosing how long a user would want the tail to be. Extra options would just be for the sake of fine-tuning the simulation for the user, and are of less priority.
Technically, based on what Processing can do, a 3D version of this program can also be made to illustrate systems of equations with three equations, where a three dimensional grid can be rotated within the space of the program, so points may be viewed from all angles. This would take a lot of work, though, and would not be the first improvement made to the program. Instead, maybe that would be developed as a side-project, made into a separate program so that this version can remain 2D.


For the finalized project, ready to be downloaded and run on Windows computers, use this link for the folder containing the exported program. Make sure you have a relatively up-to-date version of Java on your computer, or else the program cannot run properly.
If the user is running an operating system other than Windows, it is recommended that they download the Processing IDE and copy in the source code, as it is untested on other systems and may not work properly. To (hopefully) copy it properly:

  1. Download each ".pde" file
  2. Put all these files in a folder titled "diff_eq"
  3. Double-click "diff_eq.pde", and associate the ".pde" filetype with the Processing IDE if it isn't already

For the source code of the project, this link leads to a folder containing the original Processing code files, ready to be viewed, downloaded, and used in anyone else's projects, whether scholarly or recreational. It would be appreciated if a mention of the author was added to any Processing class files that are directly copied and only minimally editted. However, there is no legal obligations or licenses to restrict users from taking snippets of code, or being inspired by this to make their own version.