Support for plotting data in Fortran

1

There is a saying “The devil is in the details,” which I think applies here. Compared to MATLAB, for example, I think one of the missing details is an integrated graphics system that would allow users to easily and quickly display their results, and then later to refine those graphs for publication quality display.

Honestly, this is one of those things that I thought surely would have been developed for fortran back in the 1980s. Then over time, it would have grown from line graphs and contour plots to 3D, and then eventually to animation for molecular structures and fluid flow and so on. But that did not happen, not within the fortran standard process, not by 3rd party developers, not by the scientific and open source community. It just never happened, and I don’t know why.

8 Likes
2

Well, what about this?

(I’m genuinely interested in understanding the pitfalls of this kind of approach, besides the added dependency)

EDIT: well I’ve found some, the most prominent that as far as I understand the output terminal option to be exported to Gnuplot is hard-coded in the source, and not overridable within the API. So that a user that is not on windows has no choice to use the module except for fork away the source file and put it in his own project (which totally defeats the purpose of fpm.toml file in my opinion). I opened a relevant issue there.

4 Likes
3

Besides Matplotlib that is everywhere and was designed with Matlab syntax in mind, there are very good libraries for C++.

I believe one of the reasons is that plotting is inherently object oriented (axes, datasets, etc etc) and fortran has never been very good at that. One may think of writing an object oriented fortran interface for one of such libraries, but that would mean also creating some C middleware that is more easily done from Fortran than from C++.

In other words, it’s far easier to expose fortran calculations to a C++ graphics code than the other way around

2 Likes
4

We definitely need a native plotting library at least for the basic plots in pure Fortran that is easy to install using fpm. We can output SVG, which is just a simple xml vector format, and then use other tools to convert SVG to whatever final format is needed (png, pdf, eps, etc.).

For more complicated things we need a good wrapper over Matplotlib and/or other plotting libraries.

5 Likes
5

Native SVG plotting would actually be perfect in many many cases.

As far as matplotlib is concerned I see now that there is GitHub - jacobwilliams/pyplot-fortran: For generating plots from Fortran using Python's matplotlib.pyplot 📈, which could probably be a solid starting point. Or were you thinking more about a “true” binding to the python runtime maybe?

2 Likes
6

Plotting functions are not part of the Python, C++, or C languages AFAIK, although the matplotlib package for Python is well-known. R, Matlab, and Octave have plotting functions, but they are not just programming languages but “environments”. For example, the R page says, “R is a free software environment for statistical computing and graphics.” Fortran is a language, not an “environment”, so its lack of plotting functions is not surprising.

2 Likes
7

There have been many Fortran graphics packages, but none became considered part of Fortran, unlike some packages for other languages. That is true of many extensive packages, such as DATATRAN for statistics, the NCAR libraries for graphics, commercial libraries like TEMPLATE and Figaro and … Some still exist and there are several Fortran IDE/environments that bundle graphics libraries. Graphics was at one time owned by Fortran with some auxiliary machine code. I believe the Fortran version of the NCAR library is still available under an Apache license. Graphics turned sharply away from graphics when the X11 WIndows interface became dominant, which made heavy use of C interfaces that were difficult to call from old FORTRAN. The first relational database I used (RIM0) was Fortran. Has anyone taken a survey of what is available under open OS licenses? Perhaps something like the NCAR package is worth adapting as an fpm(1) package. It is much easier to call X11 and MSWIndows libraries than it was. I personally nearly exclusively use Fortran for basic vector graphics and basic plotting with (unfortunately proprietary) XY plots and contour plots, etc. with higher level Fortran code that calls a small C library for low level output that generates Adobe PDF, SVG, X11 Windows, … so I know it is feasible; although for presentation quality output i do often use other packages. I think there is more out there than what is being assumed here; and that creating an fpm package for some of these would be useful for Fortran and fpm as they would potentially be much more accessible to Fortran than C interfaces to one of the many available C-based or C-callable libraries.

3 Likes
8

Another option would be to open gnuplot in a pipe and write the gnuplotscript directly in one’s own fortran code.

Concerning libraries plplot might be a solution (I have not used it yet and it might be less powerful than matplotlib).

I think there is also a library for controling mathplotlib by fortran (by invoking Python).

1 Like
9

Another Fortran graphics package, which I have been using for years, is PGPLOT. It was written to be used with f77 but it works with modern gfortran in both the Linux systems I have access to. Given that it was invented by an astronomer It seems odd that its symbols do not include what LaTeX calls \varpi, which looks like a lower case omega with ~ across the top.

3 Likes
10

Well, both Python and C++ are in a situation such that the separation between the language and the “overwhelmingly dominant libraries” is in practice very blurred… the fact that Fortran has a comparatively minute and sparse open-source ecosystem is more or less the whole point. Integrated graphics is maybe too matlab-ish (but I like that, to be honest), but a powerful, native, easily integrated go to library is something that really is lacking.

1 Like
11

Woah, you made me recall a very nice historical anecdote: SCORE, a musical-engraving software that in the last century (and even further) was unanimously regarded as the best option on the market, was originally written in FORTRAN, and the graphics actually written in some form of assembly language, as reported in the dedicated Wikipedia page.

2 Likes
12

There are many plotting packages with native Fortran support (to avoid misunderstandings, by “native” I mean you can use the package by just adding Fortran statements in your program, no interoperability, no strings attached.) The “best” one is the one you like, and/or the one you are used to. I will mention just two of them.

Normally I don’t use libraries that let you plot something right from the Fortran program, but when I do, I just like PLplot. It’s easy to use, powerful, and it just works. Mathematical symbols are supported via Unicode, and that’s typically more than enough. Its LGPL license is liberal enough even for proprietary applications. Cross-platform (works pretty much everywhere,) and easily installable as well (most GNU/Linux distributions and BSDs already have it in their repositories.) Hard to find a reason to use something else, but there are lots of options anyway.

Surprisingly, nobody mentioned DISLIN yet. It’s a great package, supporting a plethora of languages including FORTRAN and Fotran 90. It has plotting procedures for pretty much everything. A big plus for DISLIN is it includes support for creating GUIs in a way I found simple and very useful, whenever a GUI is needed. Using mathematical symbols is not a problem at all because it also supports TeX expressions (and TeX/LaTeX is second to none). It is free (without restrictions), but they sell the source code, a business model I don’t see often. If you need complex mathematical expressions in your graphing output (not just symbols or simple expressions), DISLIN is the way to go.

But really, nothing beats Gnuplot, if you ask me. It is a venerable package still being developed, and it has pretty much everything I would ever need. In the past I did something like what @Jweber mentioned, using Gnuplot directly from Fortran via a pipe to a Gnuplot script. I even wrote a Fortran module that creates the script, so no need to do anything other than adding a plotting command in my Fortran program. In the end, I don’t use it much myself, I just save the data and call Gnuplot externally.

The last solution I would think of to use is to get Python or whatever else involved to do the job. I’m not denying it will work, I am just saying I see no reason to ask for “help” from another language when I do have native options, and very good ones.

It is indeed odd, but to be honest if he is an astronomer and not an astrophysicist, I doubt he needs ϖ much. That symbol (actually, a letter) is used extensively in Astrophysics. For the story, LaTeX calls it \varpi for a reason. It is used as a calligraphic variation of π in Greek for at least a millenium, and it is still used for that purpose - just rarely, in very stylized scripts. It looks like ω, I know, but it has nothing to do with lower case omega; it’s just a very calligraphic variation of pi, hence \varpi.

I beg to disagree. First of all, I see no reason to use a C/C++ library for plotting, I just have excellent native options. Second, I see no special reason why plotting must be object-oriented. Third, even if you really want it to be object-oriented, nobody stops you from implementing a Fortran object-oriented interface for one of the many native plotting packages (I’m pretty sure such interfaces do exist as well, I just never looked it up because I never needed them.) Your own object-oriented interface would be easy to implement and maintain, I might add, plus it will be tailor-made for you and not something you may or may not like how it is organized, and even worse ported from another language for no reason.
I like object-oriented programming and I do use it extensively in Fortran - but when there is a reason (that includes OpenGL applications, for example). Plotting is not in the list, simply because it is not inherently object-oriented.

4 Likes
13

I wouldn’t regard Gnuplot as a native solution and cannot understand why Python gets the “last-resort” slot and Gnuplot the “nothing-beats” one. They both are an external dependency and they both need to enter in foreign language territory (the fact that Gnuplot syntax is very shell-like makes just it worse imho).

One reason to pick python over many other alternatives it’s how much matplotlib is used worldwide and consequently how much community attention it gets. Things like xkcd colors (as a sensible improvements over X11) or perceptually uniform default colormaps really make for a greater experience, especially in the numerical computing domain. Browsing the PLplots homepage I just see ugly pure-rgb-on-black figures and awful rainbow colormaps which is really a non starter for me. Similarly with DISLIN.

I well imagine that you can customize as you want in both systems, but having well thought defaults goes a long long way with a plotting library.

1 Like
14

To be super clear: rainbow colormaps are not just subjectively ugly, they distort data and are actually dangerous for scientific representation.

Similar thoughts may apply for discrete color palettes, accompanied by the generic observation that bright pure-rgb colors scattered around in a paper or slideshow really catch the eye and distract the reader from what really matters. There’s a reason if matplotlib (or modern matlab gui, or R, mathematica, Julia… don’t use such colors).

3 Likes
15

Below is the Plotting section of my list of Fortran tools. Please reply here or raise an issue at GitHub if you know of others to be added, either free or commercial.

accis: plotting and graphics library by Ian Hutchinson. Related project: PLOTTRACES

asgl: produces a PostScript or Encapsulated PostScript file that can contain scatter plots, line plots, histograms, 2D density plots, and/or bond-and-stick plots of molecules, by Andrej Šali

CHART_COUPE: Fortran plotting package based on NCL libraries, tuned for geophysical numerical model output, from meom-group

DISLIN: high-level plotting library for displaying data as curves, polar plots, bar graphs, pie charts, 3D-color plots, surfaces, contours and maps, available for several C, C++, Fortran 77 and Fortran 90/95 compilers on the operating systems Unix, Linux, FreeBSD, Windows, Mac OSX and MS-DOS. The DISLIN distributions can be used freely without any restrictions. Access to the source code and a preferred support is available via a contract.

Dislin_x_y_plot: generates plots from within a Fortran program nearly as easily as with the provided Dislin “quickplots”, by Andi Zuend. However, unlike the quickplots, this module offers a lot more options for controlling the plot page, axis system and various curve properties. It also makes adding multiple x–y data sets (curves) to a single plot easy.

fplot: provides a convenient interface for plotting with gnuplot, by jchristopherson

fortplot: plot module for Fortran so that plotting can be done in real time (on the fly), by Anjishnu Sarkar

giza: 2D scientific plotting library built on cairo, by Daniel Price et al. Provides uniform output to pdf, ps, png and X-Windows. Written in C with no dependencies (other than cairo) as a direct replacement for PGPLOT.

gnufor2: Fortran 90 module by Alexey Kuznetsov with subroutines for plotting data, including 2D, 3D plots, surfaces, polar coordinates, and histograms. It is a modification of the GNUFOR interface written by John Burkardt.

gnuplotfortran: Fortran 95 gnuplot interface for some Unix-like OS’es, by Madhusudan Singh. This provides some routines that enables direct access of a child gnuplot session from a Fortran 95 program. fortranposix must be installed.

graffer: interactive tool for generating plots of data and/or functions, by James Tappin. The original graffer was an IDL program. This version provides most of the same functionality in a Fortran program using gtk-fortran and plplot for the GUI and plotting respectively. To display functions gdl (gnudatalanguage) or IDL is required.

M_calcomp: old graphics library used in conjunction with M_draw for work with old codes, by urbanjost. The CALCOMP library is a simple set of FORTRAN callable graphic routines that allows users to quickly construct plots.

M_slices: basic slice plot module based on M_draw(3f) and built using fpm, by urbanjost. This version requires X11 Windows.

MUESLI: numerical and graphical library, written mainly in Fortran 95, by Édouard Canot. Fortran Muesli Library contains all necessary materials to numerically work with a dynamic array (dynamic in size, type and structure), called mfArray. Fortran Graphics Library contains graphics routines which use the mfArray objects.

ogpf: Object-Based Interface to gnuplot from Fortran, by kookma

PG2PLplot: facilitate the transition from Fortran code linked against PGPlot to linking it against PLplot, which is open source and maintained. Currently, many PGPlot routines are included, but the code is by no means exhaustive.

PGPLOT PGPLOT Graphics Subroutine Library is a Fortran- or C-callable, device-independent graphics package for making simple scientific graphs, by Tim Pearson. It is intended for making graphical images of publication quality with minimum effort on the part of the user. For most applications, the program can be device-independent, and the output can be directed to the appropriate device at run time.

plotterf90: graphics subroutine library producing Postscript, by Masao Kodama

Plotutil: uses gnuplot to draw plots from data files, by Roninkoi. Has array handling utils and code for sorting and line fitting.

PLplot: can be used to create standard x-y plots, semi-log plots, log-log plots, contour plots, 3D surface plots, mesh plots, bar charts and pie charts. Multiple graphs (of the same or different sizes) may be placed on a single page, and multiple pages are allowed for those device formats that support them. C library with bindings to Fortran 2003 and many other languages.

PlPlotLib: wrapper for PlPlot inspired by the interface of matplotlib, by zoziha. It is intended to fill the need for rapid feedback while developing numerical simulations, and does not replace more sophisticated packages such as matplotlib or even direct use of PlPlot.

pltFor: Fortran-Python interface library by Damien Minenna to plot figures directly in Fortran, by calling Matplotlib

PSPLOT: library of Fortran-callable subroutines which can be combined in a calling program to produce PostScript plot files. Intended for users interested in generating technical drawings or graphics for technical journals in PostScript format.

PyFerret: Ferret is an interactive computer visualization and analysis environment designed to meet the needs of oceanographers and meteorologists analyzing large and complex gridded data sets, from NOAA/PMEL. It runs on recent Unix and Mac systems, using X windows for display. PyFerret, introduced in 2012, is a Python module wrapping Ferret.

pyplot-fortran: generate plots from Fortran using Python’s matplotlib.pyplot, by Jacob Williams

SPLASH: visualisation tool for Smoothed Particle Hydrodynamics (SPH) simulations in one, two and three dimensions, developed mainly for astrophysics, by Daniel Price et al. It uses a command-line menu but data can be manipulated interactively in the plotting window. SPLASH can also be used as a standalone plotting tool for any kind of tabulated or image data from ascii, csv or .fits files.

8 Likes
16

Default primary colors is more an artifact of how long a package has been around. At one time using anything but pure colors was pretty much unusable for lines, when the main color output device was a pen plotter, or a low-resolution screen. The packages appear to have options for supporting any color.
Trying to use any color that there was not a pen color for used to be huge mistake. Hard to believe how much that has changed; and how glaring plots look like that adhere to that old standard; but it looks easy to change. They really should look at changing those defaults.

1 Like
17

You probably didn’t read everything I wrote. I never said Gnuplot is a native solution. I made it clear in the beginning I will mention just two of the many native packages - which I did. After that, in a separate paragraph, I just added that there is also Gnuplot, which of course is an external application. And yes, nothing beats Gnuplot in my opinion, in terms of pretty much anything, graphing capabilities, plotting customization, choices of output, whatever. There is a reason Gnuplot is around for decades and it is still being developed.
You don’t like the “shell-like syntax” of Gnuplot, and that’s perfectly fine. I am guessing you don’t like Gnuplot in general, and that’s perfectly fine. I could say the exact same thing for Python’s syntax and Python in general, of course, and that should be perfectly fine as well. Actually, I don’t really have a strong opinion against Python - provided it is used where it has a reasonable use - but my point is, you are entering a very subjective area.

Quite honestly, I couldn’t care less how much “community attention” it gets - if it even gets (at least for scientific work) - which I highly doubt. Do you have concrete numbers?
And I am wondering who exactly that “community” is, and why I should follow whatever it recommends, even if said “community” exists in the first place, and if it recommends anything. Last time I checked most of the stuff that’s super trendy, even in programming, it’s usually rubbish.
Last but not least, I could name lots of reasons not to pick Python for this task…

I could say the exact same thing for matplotlib - I’m not doing that, actually, but my point is, again, you are entering a very subjective area now (except this time you try to make it look like science later on.) Not to mention you can customize the output of PLplot (and basically the output of all the native solutions) however you like. Also, it’s obvious you browsed a few screenshots on a website (which are clearly made that way to catch the eye) and you judge by that. I would do a little more research before having a strong opinion…
I may also add that even if I would ever consider borrowing a foreign, non-native, library (which I won’t, because like I said I do have excellent native options,) the last ones I would consider are the ones based on an interpreted language (and yes, I am aware of PyPy and the like - come on now.) It is really a non-starter for me. At least my decision to call it a “non-starter” is based on a little more than… colormaps on a website.

There is a huge difference between a plot you make “on the fly” (while still running the code) to inspect your results so far, a plot prepared for a presentation, and a plot being prepared for a paper. For the former, I would pick a dark background (and yes, “rainbow colors” if I so wish,) because a while background would will seem like a flash. Of course I will pick a completely different scheme for a plot prepared for a presentation, and another one for a paper. Plotting packages actually do that by default, and if you don’t like the default settings (which differ depending on the output), any of the native plotting packages will let you pick whatever else you like.

P.S.: I was about to add @Beliavsky has a list of native and non-native plotting options for Fortran programmers (he actually have similar lists for other tasks as well.)

18

Probably because up until version 11.3 it was non-proprietary only for non commercial use.
After 11.3 however they seem to have lifted the paywall for “for-profit use”.

2 Likes
19

Speaking of various types of plots, does anyone remember Random Dot Stereograms? They are an alternative to contour plots. They were popular back in the early 1990s, you could find posters in gift shops based on the idea. I even published one in a scientific paper.

The algorithm to construct these is interesting. You find intersections with the surface of the rays between the left and right eyes of the virtual viewer. The intersections determines the exact placement of the random dots, which then leads to the 3D effect. There are two versions, one for a close image that you hold in your hand, and another for an image that is far away, like on a projection screen.

For some reason they never caught on in the scientific community. They are black and white, no colors, and the viewer needs binocular vision to see them, but the image itself is very striking.

5 Likes
20

Actually, I am aware of that paper, I have a copy of it since years ago, and in fact I tried to implement the algorithm on a Fortran program in the past. The problem is my eyes never helped me see a thing in such images. Several friends could see and said they look great. Sadly, I never managed to see anything…