a pgplot question
Hi Matt, The attachement is a screenshot of the PGPLOT window that was left lying around from the last time I fired up athena. My question is about the large white-space gutter around the plot. Is there some way that I don't know about of reducing the size of that gutter? That is, can I expand the bounding box around the plot to be much closer to the size of the window? Also, what exactly does the reset argument to plot() do? And what is the most reliable way to get pgplot to *not* write a legend entry for a plot? Is it plot(a.x, a.y, key="")? Thanks B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Hi Bruce,
The attachement is a screenshot of the PGPLOT window that was left lying around from the last time I fired up athena. My question is about the large white-space gutter around the plot. Is there some way that I don't know about of reducing the size of that gutter? That is, can I expand the bounding box around the plot to be much closer to the size of the window?
Currently, this is not configurable from ifeffit. In fact, I think this is the default spacing for PGPLOT: I don't have 'throw away 25% of the area' hard-wired in! It's possible that this could be changed, but I'd have to look into it. On the other hand, PGPLOT is pretty awful and it might not be worth trying to fix it....
Also, what exactly does the reset argument to plot() do? And what is the most reliable way to get pgplot to *not* write a legend entry for a plot? Is it plot(a.x, a.y, key="")?
'reset' is intended to reinitialize the plotting color and symbol tables and restart the plotting device. I think it's been broken, probably for awhile. I'll look into fixing it. 'key=""' is supposed to cause no key to be written. But it appears that this is not working correctly either!!! I'm pretty sure this used to work. It probably gotten broken in 1.0076. At first pass, it looks easy to fix. I hope (really! a month of beamtime will end Sunday!) to have a new version late next week or early May with several bug fixes and improvements, including ebinning of mu(E) data during background subtraction, correct FTs from feffit() for data on a kgrid=/=0.05, these plotting fixes for sure, and hopefully multiple-k-weights in feffit(), a rebin() command, improvements to diffkk() and probably a few other things... --Matt
I have been like a fly on the wall, listing in on posts to this list, but I thought I would volunteer another graphics library that may be worth considering over pgplot, namely plplot. As i recall we had a brief discussion of what could replace pgplot earlier, but in the interim, I found plplot (http://plplot.sourceforge.net/). This is LGPL software (on sourceforge) that handles most scientific plots and is accessible from both C, C++ and Fortran (among others like Python and TCL). It looks like it handles most scientific plotting needs. There are example pages at the link above as well. Is it worth a look? Paul
Hi Paul, Have we had this conversation before??? Anyway, yes, I've looked at and played with PLPLOT a few times over the past couple years. It's similar to PGPLOT as far as call structure and some important advantages over PGPLOT, especially the LGPL license. It could probably replace PGPLOT in Ifeffit. PLPLOT is under active development, which is a good thing, as their make system is still quite buggy. They try to build many drivers for many languages (octave,tcl,python,java,....) and drivers. I've had problems building it from their kit on various flavors of RedHat. I tried it in January, and had to modify their Xwindows driver to work for me, which is pretty scary. It seems to work better now, but my guess is that either some build wrapper like PGPLOT_install would be needed, and might even be more extensive than the PGPLOT one. Cursor support is available in PLPLOT, but not (I believe) available from Fortran. That would have to be fixed. I tried PLPLOT on Windows once: it worked and looked better than GrWin/PGPLOT but wasn't painless. The person maintaining this is at ESRF, which is a good thing. Anyway, PLPLOT seems to be the most likely candidate to replace PGPLOT, if it gets replaced. It would be some work. Whether it would be _better_ than PGPLOT is not clear. Whether it is worth the effort is also not obvious. Another possibility is to re-interpret the PGPLOT license, and include it with Ifeffit, either as source or pre-built binaries. That is, if debian and Fink can distribute binaries and .deb files of PGPLOT source, why not Ifeffit? That would be a lot less work than using PLPLOT!! I'd also consider other plotting packages as well. The amazing R statistical package has beautiful graphics (and is GPL), but the graphics are deeply embedded and it looks like tons of work to pull them out. A final possibility would be to drop graphics from the core library and rely on the wrapper to handle the graphics. Sam is already using graphics in the GUI with SixPack. If I were starting Ifeffit now, I'd almost certainly do Ifeffit's outer layer in python, leaving only the truly numerically-intensive stuff in a compiled language. That could have many benefits, including better choices of graphics packages. This is a distinct possibility for Ifeffit2, though it would require some work to have a perl interface that Bruce could use. I think it could be workable with a client/server or service model, which could be cool for other reasons, but that's for another discussion.... --Matt
On Friday 18 April 2003 04:05 pm, Matt Newville wrote:
A final possibility would be to drop graphics from the core library and rely on the wrapper to handle the graphics. <snip> This is a distinct possibility for Ifeffit2, though it would require some work to have a perl interface that Bruce could use.
I would not necessarily be adverse to this. While I find it convenient to let the ifeffit core fret about plotting, I could live without it. There are a number of solutions which athena and artemis could take advantage of, including the Perl Data Library (which uses pgplot) and an interface between perl/Tk and gnuplot. It would also be possible (albeit a lot of work) to build a good plotter using the perl/Tk canvas. So if you were to do this, I wouldn't squawk too much. However, if you remove plotting from the core, I wonder what you would do for command line use of ifeffit. One of the nice things about the command line ifeffit program right now is that it requires neither python nor perl to do its thing. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
participants (3)
-
Bruce Ravel -
Matt Newville -
Paul Fons