4 ms·

I still don't see how this is different from matplotlib. You can also move your simulation to a different language and keep using matplotlib for plotting, with

I still don't see how this is different from matplotlib. You can also move your simulation to a different language and keep using matplotlib for plotting, with it's own scripting language Python.

leephillips 6y ago
I’ve used both Matplotlib and gnuplot extensively for visualizing the results of simulations and other tasks. I’ll try to briefly explain why I say that the gnuplot solution is portable while the Matplotlib solution is not. You don’t get plots from Matplotlib just by using Python, nor even Python + numpy. You also have to learn the conventions of the Matplotlib library, including the horrendous mechanism for making and storing settings. This amounts to learning Matplotlib’s domain specific language, which is at least as onerous as learning gnuplot’s scripting language. When you move your simulation project from Python to another language (and this is a common sequence, as people often prototype a calculation in Python but then want to make it bigger) you will be able to keep using your Matplotlib routines if your method was to store the simulation output in a file and, in a decoupled step, read and plot the file with a Python/Matplotlib program. This is a trivial form of portability that goes without saying. But you will have to maintain a Python + numpy + Matplotlib + [maybe more] ecosystem, with the Python world’s notoriously shifting set of dependencies. In contrast, gnuplot is a compiled, standalone program. There is no ecosystem to maintain. If your plotting phase was not decoupled from the calculation, and you have plotting code in your simulation code to plot things on the fly, you have to start over. Obviously you can’t use this plotting code in your Fortran program. In contrast, gnuplot has universal interfaces through sockets, FIFOs, and files. You won’t have to touch the plotting code, just trivially rewrite the lines of code that, for example, open and talk through a socket.

I still don't see how this is different from matplotlib. You can also move your simulation to a different language and keep using matplotlib for plotting, with it's own scripting language Python.

leephillips 6y ago

I’ve used both Matplotlib and gnuplot extensively for visualizing the results of simulations and other tasks. I’ll try to briefly explain why I say that the gnuplot solution is portable while the Matplotlib solution is not. You don’t get plots from Matplotlib just by using Python, nor even Python + numpy. You also have to learn the conventions of the Matplotlib library, including the horrendous mechanism for making and storing settings. This amounts to learning Matplotlib’s domain specific language, which is at least as onerous as learning gnuplot’s scripting language. When you move your simulation project from Python to another language (and this is a common sequence, as people often prototype a calculation in Python but then want to make it bigger) you will be able to keep using your Matplotlib routines if your method was to store the simulation output in a file and, in a decoupled step, read and plot the file with a Python/Matplotlib program. This is a trivial form of portability that goes without saying. But you will have to maintain a Python + numpy + Matplotlib + [maybe more] ecosystem, with the Python world’s notoriously shifting set of dependencies. In contrast, gnuplot is a compiled, standalone program. There is no ecosystem to maintain. If your plotting phase was not decoupled from the calculation, and you have plotting code in your simulation code to plot things on the fly, you have to start over. Obviously you can’t use this plotting code in your Fortran program. In contrast, gnuplot has universal interfaces through sockets, FIFOs, and files. You won’t have to touch the plotting code, just trivially rewrite the lines of code that, for example, open and talk through a socket.