About The Project
This was one of the projects I did during my Computational Physics course at Texas A&M University-Commerce. The programming and physics were a ton of fun! …learning the syntax for gnuplot wasn’t. Here’s a quick example for the terribly unintuitive syntax (and yes, the repeated colons are necessary):
plot infile using 2:xtic(1) every :::1::1 t "Healthy" lc rgb "blue", \ '' using 3 every :::1::1 t "Infected" lc rgb "dark-green", \ '' using 4 every :::1::1 t "Recovered" lc rgb "dark-yellow"
Effectiveness of Social Distancing
I incorporated a parameter to set a certain amount of the population to stay still to kind of simulate social distancing. The idea was that we should be able to get an idea for how effective social distancing is when it comes to slowing the spread of a contagion. It turns out it is pretty effective! I don’t have the results in the Github link, but I believe it came out to be that 30% of the population was social distancing, the rate of infection was halved.
Honestly, the bulk of the problems I had with this project revolved around using this plotting software. The learning curve is comparable to the base of a cliff; it was impossibly complex at first and all at once became straightforward and simple. I actually prefer gnuplot over the more popular matplotlib after this project since the software is so flexible with plotting data. If there are any academics reading this, I implore you: learn how to use this software. It made a lot of things - normally complex in Python/Matplotlib - very simple.
I did have one minor problem unrelated to Gnuplot: 10 seconds of simulation took 10 minutes to prepare. This really wasn’t a huge issue, but I liked having instant feeback when I made changes to the project, so I took a profiler to my code and found that the biggest bottleneck was with IO. Apparently opening and closing files takes a lot of time. News to me. I circumvented this by storing all the data in one file, using
\n as a delimeter to differentiate between clusters of particles at different timesteps, but alas, the program still took 8 minutes to prepare 10 seconds!
The profiler now said that the bottleneck was invoking a subprocess with gnuplot. I realized that plotting any constiuent timestep was an orthogonal task to all others. This meant that I could call all
plot(timestep) in parallel with each other and not worry about complicated stuff like race conditions. Implementing it was super easy, but it also meant that I had to start storing data for timesteps in separate files to keep things thread safe (probably didn’t have to, but I didn’t know gnuplot well enough to come up with a better solution). It also meant that each plotting task would require it’s own instance of Gnuplot, so there was a very real chance it would remain slow, or worse: become even slower. I made the changes, and got a speed increase of X10! Now, rendering 10 seconds of simulation was just short of a minute!
I might pick this project up again in the future since there is so much room for expansion. Things could be made much quicker by using CUDA and drawing with OpenGL instead of plotting.