Tag Archive | gnuplot

Very simple-minded automation of gnuplot

I have lots of datafiles I want to plot. gnuplot is scriptable. Since I don’t need any fancy output yet — this is data investigation, not manufacture of publication-quality diagrams — I can get multiple plots out quickly by writing a simple (simplish) couple of scripts.

I am sure people who know bash and perl and stuff can do this much better, but this works for me.

I have a wrapper script that simply consists of multiple calls to an inner script. It is here that I select the files I want to plot:

$ cat make_lots_of_plots.sh
./script_auto.sh r_0001_o_xy_TPA_21_Biso4p8_reread.inp
./script_auto.sh r_0001_o_yz_TPA_21_Biso4p8_reread.inp
./script_auto.sh r_0001_o_zx_TPA_21_Biso4p8_reread.inp
.
.
etc
.
.
./script_auto.sh r_0050_o_yz_TPA_21_Biso4p8_reread.inp
./script_auto.sh r_0050_o_zx_TPA_21_Biso4p8_reread.inp

I know I could do this in a single script, but I like to be able to call the inner one directly if I just want to make one plot. The inner script, script_auto.sh looks like this:

$ cat script_auto.sh
epsname=`basename $1 .inp`.eps
echo $epsname
scriptname=`basename $1 .inp`.gp
echo $scriptname
echo "set term postscript eps solid enhanced font 'Times,24'" > $scriptname
echo $epsname > temp1111
echo 'set output "' > temp2222
echo '"' > temp3333
paste -d '' temp2222 temp1111 temp3333 >> $scriptname
echo "set angles degrees; set polar" >> $scriptname
echo "set size square" >> $scriptname
echo "set xrange [-0.8:0.8]" >> $scriptname
echo "set yrange [-0.8:0.8]" >> $scriptname
echo $1 > temp1111
echo 'plot "' > temp2222
echo '" w l lw 3' > temp3333
paste -d '' temp2222 temp1111 temp3333 >> $scriptname
echo "set output" >> $scriptname
echo "set terminal x11" >> $scriptname
echo "quit" >> $scriptname
cat $scriptname
rm temp1111 temp2222 temp3333
gnuplot $scriptname
ls -ltrh $epsname

What’s going on here?

epsname=`basename $1 .inp`.eps
echo $epsname
scriptname=`basename $1 .inp`.gp
echo $scriptname

The bit above just uses basename to create the two filenames I need, one for the encapsulated postscript output, and one for the gnuplot script. Then I basically assemble the lines I want to see go into the gnuplot script. Mostly I can just echo stuff into the file, but I have various quote marks within quote marks, and (for simple-minded me) the solution that I know works is to go via the paste command, and write stuff out to little text files. I am sure there are much tidier ways to do this, but this works for me.

The line:

paste -d '' temp2222 temp1111 temp3333 >> $scriptname

causes the contents of the temporary files to be pasted together and put into the script, where the delimiter (‘-d‘) is the thing between the single quotes — which is nothing since the quotes are adjacent. This pastes stuff together with no gaps. The things being echoed into the file are gnuplot commands of various kinds.

Then I cat the script to the screen so I can see what it is doing (if I direct the output from the plotting script into a file, this lets me capture the commands I used), then I remove the temporary files, run gnuplot, and list the newly made file.

Clunky, but simple and effective. Useful changes could include outputting to pdf or some other format, and adding a step at the end (perhaps using pdfjoin) to combine all the resulting files in a single file.

Here is a png of the result. The gnuplot formatting could be made much nicer (title is too big, etc), but the overall process can always be improved, so I’m not worried about that. And the fact that it is a script means I can replot quickly when I know what the final format should be. For now I just want to see what I’ve got.

A simple plot from a diffuse scattering simulation, made using gnuplot.

A simple plot from a diffuse scattering simulation, made using gnuplot.

Whatever suits.

LaTeX for Editors: My Attempt

Last year I joined the Canberra Society of Editors, CSE. Since I am not a professional editor (though I have acted in the role for a few publications) and I have no formal qualifications, I joined as an Associate Member. When I signed up the webform asked me what I might contribute to the society. I mentioned the things I knew something about, and newsletter editor Farid Rahimi came back suggesting that a message to the society newsgroup asking whether people would like to be introduced to LaTeX might be worthwhile. We sent the message, got a handful of responses, and, well…I wrote an article.  It is here, the June 2015 issue.

A random extract from the article.

A lousy, low-res, random extract from the example document accompanying the article.  I rather like Computer Concrete as a font, though it does not look great here since the screen grab was, well, only a screen grab.

Writing an article for a magazine whose readership consists entirely of people who specialise in finding errors in written English is scary. In the end I just had to forget about the audience, write it for a general reader, and then check it over fairly carefully.  Fairly…

I decided that the topic was so wide that the best approach was to outline LaTeX’s main capabilities—logical mark-up, defining your own commands, cross referencing, good default text flow—then focus on LaTeX’s strengths and weaknesses as they pertain to editing. The change tracking facilities of modern WYSIWYG programs, most obviously Word, are very widely used tools—many modern editing textbooks have whole chapters walking the reader through the use of Word’s reviewing tools. Grammar checkers are also an issue. Equivalents to both of these tools can be found in the LaTeX universe, but they do not operate in familiar ways or provide like-for-like functionality. These things are real issues for editors.

In order to cover the ground I felt was important, yet not occupy the whole newsletter for several issues, I broke the content into two parts, a high-level review that was the actual article, and an example document that implemented many of the qualities to which I referred. The latter is available on my little download page here (cse_example.zip), a file bundle that includes all the source files needed to compile the document, including a gnuplot script that produces a graphic included using the gnuplot-lua-tikz package, a bibliography, mathematics, inputted files, and so on.

Using gnuplot and METAFONT to add Graphics to LaTeX documents

I’ve gone from looking at fonts to looking at METAFONT to looking at programs that can output METAFONT code.  It’s all slightly old technology, but METAFONT (and METAPOST) remain elegant and instructive (and useful) solutions for some problems.

This is a very basic look at using METAFONT and gnuplot to make figures for use in LaTeX. I am using Linux, but the same process ought to work for other LaTeX environments; indeed, that ought to be one of its strengths. (A quick test using DOSBox and I can see it works in DOS with emTeX.)

An archive of this little note and some associated files is available here.

1. First, on firing up gnuplot, type this:

gnuplot> help set term mf detailed

and copy the result to a text file (I just used cut and paste off the screen). It is 90% of what you need, maybe more if you are more knowledgeable than me.

2. Then type something like this:

gnuplot> set xrange [0:3.14159]
gnuplot> plot sin(x), cos(x)
gnuplot> set term mf
gnuplot> set output "test2.mf"
gnuplot> replot
gnuplot> exit

3. Then edit the resulting file test2.mf and read the bit that says:

%Include next eight lines if you have problems with the mode on your
%system..
proofing:=0;
fontmaking:=1;
tracingtitles:=0;
pixels_per_inch:=600;
blacker:=0;
fillin:=.2;
o_correction:=.6;
fix_units;

and think about uncommenting bits. I uncommented all of it, as you can see, but maybe I did not have to.

4. Then type something like:

$ mf '\mode=ljfour; input test2'
$ gftopk test2.600gf

and have a look at the files you have created; you ought to see test2.600pk/gf and test2.tfm.

5. If you like at this point you can try:

$ gftodvi test2.600gf
$ xdvi test

and you should see the picture appear in the .dvi file (though the ‘gray’ font is needed for this, and that can be quite another story. If this does not work just go on).

6. Now, you want your LaTeX file to be able to use your figure. It does so as a font rather than as a graphic. Since LaTeX (and TeX) can handle fonts natively but uses external packages to import other graphic formats, this is a strength of the approach, though less important in these days of very powerful machines.

Create a simple .tex file. Put the below in the preamble (though it can go anywhere you like as long as it’s before you want to use the figure):

\font\gnufigs=test2

This tells the typesetting program that you want to use a font called ‘gnufigs’, and that the information about this font is in files called test2.tfm and test2.XXXpk where XXX is the dots-per-inch (600 in the example above).

The picture is character 0 (zero) in your ‘font’. Indeed, if you’ve only done as I suggest here, it is the only character. To insert it you just type:

{\gnufigs \char0}

somewhere in your file. You can embed this in a figure environment if you want the usual LaTeX cross referencing. See for example figure 1. Note that this does not use \includegraphics, so does not have access to all the formatting, scaling, cropping and other options of that command.

"The

7. What if it doesn’t work?

If your dvi viewer or whatever you are using to convert the .dvi file to another format (PDF, PostScript, etc) complains that it can’t find the font, it may mean that is is not clever enough to generate the pk file that it needs from the output. What I have done above generates 600 dpi output, but your system may want something else. Best thing is to put the required dpi (it should be apparent in the error messages) into the top of the .mf file — as noted above, there are some fields to uncomment if you like, and they can also be edited. Then run gftopk on the resulting .XXXgf file and you should be away. The mode flag on the command line may need to be altered or removed, I’m not sure.

You may find that dvipdfmx does a better job of making a PDF from the .dvi file than going via PostScript. I find that the PostScript from dvips looks good but ps2pdf sometimes does not give a good PDF file where dvipdfmx does. It’s probably something to do with search paths — perhaps ps2pdf does not search the current directory.

8. Some more details.

LaTeX (and TeX) need only the .tfm file to typeset the document — it contains the information on the sizes and so forth of the characters. But rendering the ‘glyph’ needs the pk file.  I find it simplest to leave these font files in the working directory. It makes little sense to install a graphic as a font system-wide.

Keep in mind that gnuplot is scriptable. It can be run from the command line. All the other steps can be similarly automated. That means that this is a nice path for incorporating graphics that may themselves need to be updated. Say you are using gnuplot to plot a text file full of data. If that text file changes, you can just rerun a script that calls gnuplot and runs and any ancillary programs you need. This allows the graphics to be dynamically updated without having to manually update them. A similar thing can be done with other forms of output from gnuplot, of course.

Why oh why?