I'm trying to get a script to work in batch mode to produce a large number of
plots. I've got the following sequence of imports in a matplotlib Python
script:
At first this appeared to work without any problems. I could kick off a job
in background, log off the machine and return later when all the graphs had
been produced.
Now I get this RuntimeError exception. Is there anything else I need to do
to convince matplotlib that it doesn't need my local display?
Without the stack trace, it would be hard to tell. Plus, there is already logic in the backends to switch to PDF and such for saving files. It should only be necessary to set the backend to AGG if you want a headless batch script.
Ben Root
···
On Thursday, September 1, 2011, CompBio <rogersma@…3760…> wrote:
I’m trying to get a script to work in batch mode to produce a large number of
plots. I’ve got the following sequence of imports in a matplotlib Python
script:
At first this appeared to work without any problems. I could kick off a job
in background, log off the machine and return later when all the graphs had
been produced.
Now I get this RuntimeError exception. Is there anything else I need to do
to convince matplotlib that it doesn’t need my local display?
I'm trying to get a script to work in batch mode to produce a large number of
plots. I've got the following sequence of imports in a matplotlib Python
script:
Is the script being run standalone, from a shell, and are the following the very first imports?
As Ben notes, you don't need the above logic to choose between agg and pdf; but you are correct in choosing a non-interactive backend before any import of pylab or pyplot. That should be enough to prevent any subsequent attempt to open a display.
I'll bet the problem is that when the code above is run, file_ext is neither 'png' nor 'pdf', so matplotlib.use is not being executed.
from pylab import *
And at this point pylab is simply setting the default (interactive) backend.
... remainder of plotting code ...
At first this appeared to work without any problems. I could kick off a job
in background, log off the machine and return later when all the graphs had
been produced.
Now I get this RuntimeError exception. Is there anything else I need to do
to convince matplotlib that it doesn't need my local display?
No--you just have to make sure that a non-interactive backend is getting set before the first pylab or pyplot import.
Thanks for your fast response -- faster than I could post a follow-up.
You're right about the stack trace. It occurred to me after I posted that I
should look to see exactly where the exception was triggered. As it turned
out, I'd added a new module a few days ago and wasn't careful about where I
added the import. Here at work it didn't make a difference, but launching
from home...
Once I reordered the new import the error disappeared.
BTW, the reason I specify a PDF backend is because I thought it would tell
matplotlib not to try to use anything else "behind the scenes" such as an
X-window display. It's working the way I want now, so I assume that's what
it's doing.
Benjamin Root-2 wrote:
···
On Thursday, September 1, 2011, CompBio <rogersma@...3760...> wrote:
I'm trying to get a script to work in batch mode to produce a large
number
of
plots. I've got the following sequence of imports in a matplotlib Python
script:
At first this appeared to work without any problems. I could kick off a
job
in background, log off the machine and return later when all the graphs
had
been produced.
Now I get this RuntimeError exception. Is there anything else I need to
do
to convince matplotlib that it doesn't need my local display?
thanks!
--
Without the stack trace, it would be hard to tell. Plus, there is already
logic in the backends to switch to PDF and such for saving files. It
should
only be necessary to set the backend to AGG if you want a headless batch
script.
Ben Root
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net matplotlib-users List Signup and Options
and when you call savefig, you can pass ps, eps, pdf, png or svg and
the mpl code will choose the right backend, and never launch a GUI.
JDH
···
On Thu, Sep 1, 2011 at 1:23 PM, CompBio <rogersma@...3760...> wrote:
BTW, the reason I specify a PDF backend is because I thought it would tell
matplotlib not to try to use anything else "behind the scenes" such as an
X-window display. It's working the way I want now, so I assume that's what
it's doing.
First, you folks respond faster than lightning -- I can't keep up!
Second, thanks for the tip -- that's definitely more elegant than my callow
approach.
John Hunter-4 wrote:
···
On Thu, Sep 1, 2011 at 1:23 PM, CompBio <rogersma@...3760...> wrote:
BTW, the reason I specify a PDF backend is because I thought it would
tell
matplotlib not to try to use anything else "behind the scenes" such as an
X-window display. It's working the way I want now, so I assume that's
what
it's doing.
But at others have pointed out, your code is unnecessarily complex. Just
do
and when you call savefig, you can pass ps, eps, pdf, png or svg and
the mpl code will choose the right backend, and never launch a GUI.
JDH
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net matplotlib-users List Signup and Options