I would like to ask some opinions on the interface choice when writing modules/library. When I write HPC code, I find it difficult to parallelize the object that contains every array of the model I am solving. It seems to me that it is easier to parallelize procedure code.
On the other hand, when I wrote the following plotting library for fortran, I followed my experience in utilizing procedure programming for the interface, while most plotting libraries in fortran use OOP. (e.g., ogpf, pyplot-fortran). I am guessing that we don’t need this library in HPC or parallel computing, so perhaps OOP might be a good option; however, I also enjoy the fact that sometimes I can just call the function like call tikz(x, y) and then I can generate a plot with default setting.
Thank you for you comments, I would like to thank you for reading this in advance.
Btw, I added the groupplot and surf plots in tikz-fortran. Feel free to give me ideas on what you will be interested to see next. Maybe bar chart?
I have a similar library that can create a line plot with gnuplot with just call plot(x,y) and agree it is convenient. Whether to make plots in a program is something you would like to toggle, and it is convenient to write
if (make_plots) call plot(x,y)
rather than use multi-line if blocks. Optional arguments can be used to change settings, and to plot several y’s vs. x you can pass a 2D array for y and use an interface:
interface plot
module procedure plot_xyvec, plot_x_ymat
end interface plot
I should work on it more and put it on GitHub. There are at least 3 OOP libraries on GitHub to call gnuplot from Fortran:
fplot: provides a convenient interface for plotting with Gnuplot, by jchristopherson
libgnuplot-fortran: routines for plotting inside Fortran using Gnuplot, by JoseAntonioLattice
ogpf: Object-Based Interface to GnuPlot from Fortran, by kookma
There needs to be a good balance between how you use things, not everything has to be an object, while not everything has to just be procedural code. I feel that objects are good for maintaining readability in many parts of the code and the performance critical steps can be done more procedurally. I wouldn’t shove all arrays into a single object, I’d have objects that contains objects that contains the arrays and then you operate on the arrays.
Difficult to discuss without looking at what code you’re writing, but I feel that there’s always a balance. It is difficult, though.
Yes, that is exactly how I did it. Having module procedure at for different inputs, as in the this chunk of code.
I also separate the data file from the plotting tex file so that if there’s some setting the module cannot provide, at least it is easier to modify the plotting tex file.
Now my programming style is mostly procedure for HPC modelling. I let most of the variables that will carry over different subroutines and functions to be global variables. I don’t know whether it is a good practice. Probably not as there is some possible side effects, but at least it works for me now.
Sometimes I still think that OOP is good to avoid all side effects that comes from the global variables approach without having 40 arguments for subroutines. I think I need to find a systematic way or principle to ensure the balance between readability and performance hurdle, yet I haven’t found it.
