Based upon the IDL experiences of Miranda Balkin, Kate Becker, Mark Kramer, and Jim Sheckard, and written by Kate Becker and Miranda Balkin
June, 1998
Contents
Section
One: What's all the fuss about IDL?
Section
Two: Running IDL
Section
Three: What is a good way to start learning IDL?
Section
Four: Arrays
Section
Five: Plotting
Section
Six: Creating and running procedures
Section
Seven: Saving and printing images
Section
Eight: Widgets
Section
Nine: Where to go for more information
Appendix:
Email help
Welcome to our friendly guide to IDL! In the following text, we hope to provide you with some simple information about IDL. We decided to create this guide because of our own difficulties learning IDL, and hope that this guide is helpful for those with little previous programming experience.
Section Two:
Running IDL
There are two
ways to run IDL: directly from the command line, and through IDLDE.
We have generally found IDLDE to be much easier to work with. To
start IDLDE, type idlde at the UNIX prompt (not the IDL prompt).
IDLDE provides a familiar looking setup with menus, access to help, and
the like. The IDLDE screen is divided into several parts, three of
which contain text that you entered: the code for the program you are working
with appears in the editor window (which works similarly to a word processing
program), the middle section saves previously entered commands and delivers
IDL's error messages, and the command prompt is where you enter commands
on a one-at-a-time basis.
To start the
traditional version of IDL, type idl at the UNIX prompt. There
is also a utility called IDL Insight which, from the demos, seems like
it would be easy to work with. However, while we didn't spend much
time working with Insight, it seems too simple: you will find that when
you need to use IDL or IDLDE, you won't know what you're doing. Also,
it doesn't appear to have all of the main program's capabilities.
Our advice, then, is even if you start out by practicing with Insight,
don't be tempted to spend too much time.
Section Three:
What is a good way to start learning IDL?
Our group tried
what was pretty much a total-immersion approach. Other routes, however,
may be more profitable. The IDL Basics book, for instance,
provides a decent number of tutorials. The problem with this particular
book is that, although it guides you through IDL, it doesn't generally
explain why you are doing what you are doing. It will familiarize
you with some useful IDL commands, though, and will also provide an opportunity
to create the aforementioned pretty graphs all by yourself. A few
chapters of Using IDL may also be helpful, specifically chapters
2, 9, 10, 11, 13 and 14. This manual does assume some knowledge of
programming, though, so be prepared. Building IDL Applications
prepares you to do just that. If you have no programming background
at all, you may find it helpful to begin by reading one of those For Dummies
books, or at least getting familiar with Unix.
Section Four:
Arrays
Arrays are basic to IDL.
An array is a set of numbers arranged in a particular order and geometry;
in other words, a set of data. Arrays in IDL can have up to three
dimensions. A one-dimensional array is equivalent to a vector.
A two dimensional array is like a matrix, with a set number of rows and
columns. If a two dimensional array thus resembles a rectangle, a
three dimensional array is like a cube. Karen Hole's procedures use
primarily two dimensional arrays (dynamic spectra and the outcomes of processing
these spectra): one dimension is time, one frequency, and then intensity
of pixel indicates intensity of signal.
Arrays can be
created in a number of ways. First, you can directly enter the numbers
which will make up the array. For instance, for a two dimensional
array of two rows and three columns, you would type:
array=[[1,2,3],[4,5,6]]
Page 130 of Using IDL provides
more information on this.
Another way
to create arrays involves IDL's array creation routines. There is
a list of them in the IDL Handiguide (that tiny booklet that lists
all the commands IDL knows); the ones we've used most frequently have been
INDGEN and FINDGEN. These both create one dimensional arrays in which
each element of the array is equal to its subscript. In other words,
the zeroth element of the array is 0 (these arrays begin with 0, not 1),
the first element is 1, the second is 2, and the last element of an n-element
array is n-1. The difference between FINDGEN and INDGEN is
that FINDGEN creates a floating point array--that is, the elements have
movable decimal points--while INDGEN creates an integer array--no decimals.
(A description of the different data types that can make up an array is
on page 126 of Using IDL.) To create an array in this way,
type:
array=findgen(10)
IDL almost never cares about whether you capitalize. It knows its commands whether they are capitalized or not, but be sure and be consistent about whether you capitalize the names of your arrays. You can look at your array by typing
print, array
You can also manipulate the array as you see fit. For instance,
array=array/2
will return your original array
with each element divided by 2. This may seem a little confusing
at first, like saying that 1=1/2, but IDL merely reformulates the data
values to half of their original values. It will only remember their
most recent values, in other words, what you have last done to them--to
recall the values before you halved them (or whatever you did), you will
need to recreate your beginning data set.
You can take one element from an
array by typing
mynumber=array[3]
array[3] will give you the third
element of the your array.
For more fun with arrays, try adding
two arrays together:
idl=[1,2,3]
you=[4,5,6]
fun=idl+you
Chapter 9 of Using IDL provides more information on operators you can use with arrays.
Section 5:
Plotting
Chapter 10 of Using IDL
gives fairly helpful explanation and examples of plotting. Also,
the "Simple Commands Yield Powerful Results" section of IDL Basics
(pages 3-5) gives a short tutorial with thorough explanation. Here
is another short example. First, create an array to plot.
a=FINDGEN(100)
b=reverse(a)
c=[a, b]
This creates a 100-element array, then creates a second array with the same elements in the opposite order. It then concatenates these arrays (inserts b at the end of a). To plot the result, enter:
plot, c
Wow! It's a minimalist pyramid!
Other valuable things to try include
the following:
Using IDL pages 157-163
(PLOT and OPLOT)
pages 174-175 (Logarithmic Scaling)
pages 176-177 (Multiple Plots on a Page)
pages 178-179 (Specifying the Location of the Plot)
pages 179-180 (Plotting Missing Data)
pages 180-182 (Using the AXIS Procedure)
pages 182-184 (Using the CURSOR Procedure)
pages 186-192 (Contour Plots)
Section
6: Creating and Running Procedures
A procedure is a series of steps
that tell IDL to do anything from adding 2+2 to taking a histogram and
secondary spectra of your data and displaying them, in full color with
interactive capability, on the screen. Unless the procedure you're
creating is exceptionally short, you will want to write the procedure in
the top box (editor window) of the IDLDE screen. The first line of
the procedure should be
pro name
where name is, happily, the name of your procedure. The rest of your procedure should follow, and the last line of the procedure should be
end
Here is a sample procedure:
pro test
a=findgen(200*!pi)
a=a/100
plot, sin(a), title='My
Wonderful Creation'
print, 'The creation is
complete!'
end
This procedure creates a 618-element
array (200 * pi). The ! preceding the pi indicates that pi is a system
variable, i.e. a variable that IDL already knows. The instruction
to print The creation is complete! is, admittedly, totally unnecessary
to this procedure. However, the print command could be useful in
other procedures. For instance, in debugging, including print commands
after each part of the procedure can help you figure out where the problem
is. However, print should actually be reserved only for emergencies,
for reasons to be discussed later.
To run this
procedure (we know you're just trembling with anticipation), first save
it as test.pro in your working directory. If you want IDL
to recognize a procedure and be able to run it, it must be in the directory
in which you currently reside, or its pathname must be explicitly specified.
Also, its filename must always be of the form procedurename.pro.
You are only
seconds away from seeing the procedure in action! But first, you
must compile the procedure. From the run menu, select compile
test.pro. Compiling translates the procedure from IDL language into
machine language, so that the computer can understand it. Yes, the
big moment has arrived. Select run test from the run menu.
A plot should pop up and The creation is complete! should appear
in the middle (message) window. Just let the awe sweep over you.
The following
is another example, which demonstrates how one procedure can "call" another.
pro testagain
loadct, 13
test
end
This procedure begins by loading
a new color table (IDL comes equipped with 40 color tables; to see them
all, enter xloadct). It then calls test, which proceeds
to do its plot, and then ends the procedure. To run testagain,
save it, compile it, and run it.
The following
example demonstrates how a procedure can pass another procedure information.
Change test.pro so that it reads:
pro test
common block, b
a=findgen(200*!pi)
a=a/100
plot, sin(a), title='My wonderful
Creation'
if (b eq 1) then begin
oplot, cos(a)
endif
print, 'The creation is complete!'
end
And create a new procedure which reads
pro btest
common block, b
b=1
end
btest defines a variable,
b, and puts it in the common block, a block of information shared
by different procedures. Thus, it passes the value of b to
test. You may have as many common blocks as you like, to share
different variables within different procedures (you may have a whole network
of interdependent procedures at times), and you can name them anything
you like: common color, for example, or common spiders.
Test then employs an if-then statement to decide whether or not
it will overplot the cos of a: if btest indicates that b=1,
test will overplot cos(a), but if b does not equal
one, test will plot only sin(a). Endif indicates
that any following instructions are independent of the value of b.
There is more information on if-then statements on page 98 of Building
IDL Applications.
Section 7:
Saving and Printing Images
We spent many
many hours trying to understand saving and printing with IDL, so in this
section, we hope to spare you a little bit of the horror of this experience.
It is relatively simple to save an image in a number of formats, including
bitmap, GIF, JPEG, and PICT (for more information, see the IDL Reference
Guide, pages 1084-1092). Enter:
write_PICT, filename, image
where write_ is followed by the type of file you want to create (bitmap is written as BMP), filename is the name of your file, and image is the source of the image. Our favorite way to do this was to set the image as
tvrd( )
In other words, you would type
write_PICT, filename, tvrd( )
This saves whatever image you are
currently working with. It does have one significant problem, though,
in that it saves the image as it appears on the screen. If you happen
to be working with Windows NT, you may notice that IDL images don't usually
refresh properly, and will not be complete if they are partly hidden behind
another window. tvrd will only capture that part of the image
that is visible. For more information, see the Reference Guide,
page 950.
Viewing these
images is somewhat trickier. You can try it with the xv viewer on
PSR4, or with the image-viewing programs on the Windows machines, but our
experience suggests that this won't work very often, and when it does choose
to work, you won't know why. We had the most success going to the
computing center in Mudd, ftp-ing the images from the lab, and viewing
them with Adobe Photoshop. Unfortunately, printing images from Photoshop
resulted in a substantial drop in image quality. Which leads us to
the real way to create images: postscript.
You may notice
that many of the emails in the appendix to this guide are about postscript.
This is because we had something of a miserable time trying to make postscript
work. Here is what we've learned.
You must precede
your plotting instructions with
set_plot, 'ps'
device, filename='filename'
where the second filename only is the name of your file. This must be followed with
close, /device
set_plot, 'x'
The set_plot, 'x' command is VERY VERY IMPORTANT. Set_plot tells idl what 'device' to send the plot to: 'x' is the screen, 'ps' is a postscript file. Because screens and postscript files are very different things, you will get all sorts of horrible errors if you forget to change the device back to the screen. Also be careful if you are running a procedure which includes a change of devices and the procedure does not run all the way to the end: though the set_plot, 'x' line may be present, if the procedure never gets to it, it doesn't do any good. A quick way to test that your current device is the screen is to type
wdelete, 0
This tells idl to delete the window in which your plot appears from the screen (it will work whether or not there is actually a plot on the screen). If the screen is not the current device, you will get an error. Type
set_plot, 'x'
and the error should be corrected.
We also had
a great deal of difficulty figuring out how to print images once we had
saved them. Our new favorite way to print is the following:
$lp filename.ps
from IDL, or just
lp filename.ps
from the UNIX prompt (you may have to use lpr instead of lp, depending on which Unix system you are using). The .ps indicates that the file is a postscript file; if it were something else, it would have a different extension, for instance, a bitmap file would be filename.bmp, a GIF would be filename.gif, etc.
Section 8:
Widgets
Widgets create
buttons, sliders, and other handy adjustable parameters that look very
professional and can be called with an image or a procedure to interactively
modify it, just like xloadct. Complete documentation on widgets
can be found in the manuals: creating them is fairly simple if you follow
the instructions. In a procedure that includes widgets, you first
need to create an event handling program (if your procedure is called analyze,
your event handler can be something like analyze_event). This
will tell the procedure what to do to your data once the button is pressed,
the slider is moved, or the menu is pulled down. After this, within
the same file (after the word end and after you've told it everything
you need to do--although chronologically speaking it is probably simpler
to write this part last), you write your procedure analysis. This
will mostly create the widgets themselves--which by the way you can create
all by themselves without any event handling. They don't mind. In
that case, you call your procedure and the widgets will show up on the
screen and can be manipulated just as if they meant something, but whatever
you do to them, nothing will happen. Rest assured they won't crash
anything. You can also create draw widgets, which bring up
images of your data. You can create dialogs which will give the user
the option of choosing which data file she wants to open. Instructions
on all of this are in the help manuals. There are lots of nifty widget
examples in the IDL demo, especially the FFT (fast fourier transform) demo.
Widgets can also be named anything you want (but don't get too obscene).
Section 9:
Where to go for more information
The IDL Online Help, which
you can access by clicking on the Help icon in IDLDE, is usually reasonably
helpful, though it mostly repeats information you can find in the reference
guides. RSI Technical Support is also handy; however, email to them
should go through Mr. Stinebring first. There is also a lot of information
available on the internet. For instance, the
IDL
Astronomy Library at NASA has a large database
of IDL procedures that you can download. When these procedures work,
they can make your life considerably easier. They don't always work.
This site also
directs you to a list of other IDL sites, including faq and the like.
You can also try the official
IDL page. There is also an IDL consultant who has his
own page.
Date: Thu, 28 May 1998 22:50:50
-0600
From: RSI E-mail Support <support@rsinc.com>
To: "'Dan.Stinebring@oberlin.edu'"
<Dan.Stinebring@oberlin.edu>
Subject: RE: print directly to
a PS printer
Dan,
Here is an example of sending output
directly to the system printer:
-At the IDL prompt enter:
result=dialog_printersetup()
- In the Printer Setup dialog window,
if "Printer Specific" is not already chosen, select it.
- If the printer indicated is not
the desired type and settings then choose the Options button.
- Select the desired options from
the Options dialog and hit Okay.
- If the correct printer is not
listed, cancel back to the setup dialog and choose the Install button.
- Then choose the Add Printer button.
- From the right hand list, choose
the printer type for your system.
- From the left hand list, choose
the desired printing command.
- If the desired command is not
listed, hit the Define New Port button and specify a command. For
example, you might enter:
my_lp=lp
and then you should choose Add-Replace
to enter the command to the list. Or by choosing the Spooler button
a command for you. Then select Dismiss.
- Back in the Add Printer dialog,
then select the correct Printer Device and the Port Definition and then
Dismiss.
- Dismiss out of the Printer Installation
dialog back to the Printer Setup dialog.
- Choose Options again and then
select the desired printer/command item as well as the desired options
and then hit Okay.
- Specify the remaining settings,
hit Save and then Apply.
- At the IDL prompt enter:
set_plot,'printer'
- You might then enter the command:
plot, indgen(10)
-Close the printer device to send
the output to the printer:
device, /close
- Then reset the output device
to X: set_plot,'X'
I hope this will be helpful.
Best regards,
Jim Uba
___________________________________________________________________
Date: Wed, 03 Jun 1998 16:20:45
-0600
From: RSI E-mail Support <support@rsinc.com>
To: "'kate.becker@oberlin.edu'"
<kate.becker@oberlin.edu>
Cc: "'Mark.Kramer@oberlin.edu'"
<Mark.Kramer@oberlin.edu>
Subject: Case Id: 980603451326
Printing From IDL
Kate and Mark,
I am currently working on your questions on printing from IDL. As far as the question about a small spade on your printouts, I do not fully understand this problem because IDL printout do not normally have a small spade on them. Therefore, I will need to see the process you are using to obtain printouts from IDL. Thus, please e-mail me back a detailed description (maybe even the code itself if it is small, less than a page) of the task you use to produce this output.
As far as the question about printing out results from IDL with finer resolution than PICT or TIFF output, you should consider using IDL's SET_PLOT procedure to change the display DEVICE to either directly to a printer (SET_PLOT, 'printer') or a PostScript file (SET_PLOT, 'PS'). The PostScript option will provide the best resolution. For more detailed information on SET_PLOT and these DEVICEs, please consult IDL's Online Help (enter in a question mark at the IDL Command Prompt). The description of the SET_PLOT procedure is under the "Alphabetical List of Routines" menu. The descriptions of the PRINTER and PS DEVICEs are under the "Graphics Devices" option of the "Language Features Quick Reference" menu. All of these descriptions contain examples.
Hopefully, this information helps. When you e-mail me back, please put my full name somewhere near the top of your letter. We have quite a few Davids here.
Sincerely,
David Vandenbelt, RSI Technical
Support Engineer
___________________________________________________________________
Date: Fri, 05 Jun 1998 00:00:39
-0400 (EDT)
From: Dan Stinebring <dan@physics.oberlin.edu>
Reply-To: Dan.Stinebring@oberlin.edu
To: Team Pulsar 98 -- Jim Sheckard
<jsheckar@physics.oberlin.edu>,
Kate.Becker@oberlin.edu,
Mark.Kramer@oberlin.edu,
Miranda.Balkin@oberlin.edu
Cc: Dan Stinebring <dan@physics.oberlin.edu>
Subject: Postscript help
Hi,
There are several good sources of information about Postscript within IDL that I have found for all you budding Postscripters. They are:
1) within IDL Help look at
Postscript
device
Many of the questions we have been
asking are answered in this
documentation. If you read
it through you will find lots of useful
information and examples.
2) on the Web look at
http://fermi.jhuapl.edu/www/s1r/idl/idl_faq/idl_faq.html (note: this URL doesn't work)
for answers to some frequently asked
questions (FAQ) about IDL. In
particular, technical questions
T12, T14, and T28 all pertain to Postscript.
-- Dan
___________________________________________________________________
Date: Fri, 05 Jun 1998 00:49:05
-0400 (EDT)
From: Dan Stinebring <dan@physics.oberlin.edu>
Reply-To: Dan.Stinebring@oberlin.edu
To: Team Pulsar 98 -- Jim Sheckard
<jsheckar@physics.oberlin.edu>,
Kate.Becker@oberlin.edu,
Mark.Kramer@oberlin.edu,
Miranda.Balkin@oberlin.edu
Cc: Dan Stinebring <dan@physics.oberlin.edu>
Subject: IDL - Postscript gray
scale
Hi,
I've done some poking around on
how to get the gray scale to be inverted when using Postscript. That
way the background will be white and the most intense features (strongest
signal) will be black, as desired.
This procedure, which can be found
in
/d2/140sp/analysis/IDL_Dan/test_ps_gray.pro
will do it:
pro test_ps_gray
a = rebin(bindgen(256),256,50)
; creates a 256 x 50 element color bar
; this is the data that gets plotted
set_plot,'ps'
; open the Postscript device
device,/color,bits_per_pixel=8
; using color allows you to change the
; color table
c = reverse(indgen(256))
; reversed - suitable for Postscript
tvlct, c, c, c
; establish the color table
tv, a, 0, 0, xs=5.0, ys=1.0,/inches
; note size of output in inches
device,/close
end
-- Dan
___________________________________________________________________
Date: Fri, 05 Jun 1998 10:48:22
-0400 (EDT)
From: Miranda Balkin <mbalkin@physics.oberlin.edu>
To: Dan Stinebring <dan@physics.oberlin.edu>
Cc: Team Pulsar 98 -- Jim Sheckard
<jsheckar@physics.oberlin.edu>,
Kathryn Becker
<Kate.Becker@oberlin.edu>, Mark.Kramer@oberlin.edu
Subject: Re: Postscript help
The FAQ site is an invalid URL, but there is some help on IDL techniques on the server that looks like it might be good, including a page on a PostScript utility I haven't looked at yet.
http://fermi.jhuapl.edu/s1r/idl/s1rlib/local_idl.html
-Miranda
___________________________________________________________________
Date: Fri, 05 Jun 1998 13:47:02
-0400 (EDT)
From: Dan Stinebring <dan@physics.oberlin.edu>
Reply-To: Dan.Stinebring@oberlin.edu
To: Team Pulsar 98 -- Jim Sheckard
<jsheckar@physics.oberlin.edu>,
Kate.Becker@oberlin.edu,
Mark.Kramer@oberlin.edu,
Miranda.Balkin@oberlin.edu
Subject: RE: IDL Contour questions
(fwd)
Here is some help from the IDL people that Karen got when she was working on the contour/TV overlay problem.
I hope this is helpful.
-- Dan
---------- Forwarded message ----------
Date: Mon, 20 Oct 1997 10:06:15
-0600
From: RSI E-mail Support <support@rsinc.com>
To: 'Dan Stinebring' <dan@physics.oberlin.edu>
Subject: RE: IDL Contour questions
Dan,
I started looking into your CONTOUR questions on Friday and because of the number of questions, it is took me a little while to get all of the information together. I will address each question individually below. If you have any additional questions or comments about these specific topics, please feel free to contact me through the direct phone number or email address listed below my signature. Again, sorry for the delay.
>1) She can't figure out how to
get the axes labeled for a greyscale plot;
>Is there a way to do this?
She had to resort to overplotting with a contour plot, giving an image
result which we now like.
By greyscale plot to you mean the image that you are passing to TVSCL? TV and TVSCL do not establish axes, as these routines are used to display images.
>2) When she does the overplotting the axes are labelled by array index value rather than by the physical units -- time and frequency -- we are dealing with. What is the mechanism for setting a different scale on the axes?
To set the specific values of the axis for your contour plot, create an array of values for x and y axes, then pass those arrays into your CONTOUR plot. For example, the followin code fragment creates a 10x10 contour plot, with x values in the range of 0-90, and y values in the range of 0.0-1.0. The x array needs to have the same number of elements as the x dimension of the data array. The same applies for the y array.
data=dist(10)
x=findgen(10)*10
y=findgen(10)/10
CONTOUR, data, x, y >3)
The greyscale and contour plot routines seem to use their own --different -- default values for the starting and ending values of the axes. How do we get them to plot to the same exact scale so that they can be exactly overlaid?
The best way to produce an image with a contour is to first contour your data with the /NODATA keyword. This establishes your axis for the data. Next get the values of !P.CLIP. The values in this system variable are the x&y locations of the lower-left and upper-right corners of the "plotting" region. The array returned from !P.CLIP is a 6-element array, in the form [x0, y0, x1, y1, z0, z1]. Then resize your image based on the size of the "plotting" region (x1-x0, y1-y0). For the example code below, I used the CONGRID routine to resize the data. TV (or TVSCL) the resized image (be sure to use x0 & y0 to correctly offset the image). Finally, contour your data with the /NOERASE keyword. Take a look at the sample code below and let me know if you have additional questions.
data=dist(500)
contour, data, /nodata
plotRegion=!p.clip
resizedImg=CONGRID(data, (plotRegion(2)-plotRegion(0)),
(plotRegion(3)-plotRegion(1)))
Loadct, 5
TV, resizedImg, plotRegion(0),
plotRegion(1)
Loadct, 0
Contour, data, color=155, nlevels=9,
/noerase
4) What is the procedure for changing
the aspect ratio of an image: we'd
like to replicate rows of our current
image to make it (4 x 99) x 512 instead of
99 x 512.
Do you wish to actually replicate the rows of your image, or do you wish to resize the image? This question is a little bit vague. You have an image that is 99x512 and you want to create an image that is (4x99) x 512. Do you want each row to be exactly replicated 4 times, or to you want IDL to perform a type of interpolation as it resizes the image?
5) Finally, on another item that has come up, we have a 2-d array that is divided into four quadrants. We need to shuffle those four quadrants around -- like four pieces in a jigsaw puzzle -- to reassemble the array properly. What routine should we use to do this?
The easiest way to rearrange you data array is to use IDL's native array manipulation techniques. Just create a new array with the same dimension as the first, then place the quadrants of the original array into the correct position in the new array. Take a look at this code fragment.
originalData=dist(100)
newData=fltarr(100, 100)
window, 0
contour, originaldata
;Move orig quad 1 to new quad 4
newData(50:99, 50:99)=originalData(0:49,
0:49)
;Move orig quad 2 to new quad 3
newData(0:49, 50:99)=originalData(50:99,
0:49)
;Move orig quad 3 to new quad 2
newData(50:99, 0:49)=originalData(0:49,
50:99)
;Move orig quad 4 to new quad 1
newData(0:49, 0:49)=originalData(50:99,
50:99)
window, 1
contour, newData
Again, let me know if you have any
additional questions or comments about these specific topics.
Best Regards,
Dave Sausville
Research Systems Inc.
Technical Support Engineer
___________________________________________________________________
Date: Fri, 05 Jun 1998 18:14:58
-0400 (EDT)
From: Kathryn Becker <Kate.Becker@oberlin.edu>
To: jschekard@physics.oberlin.edu,
mkramer@physics.oberlin.edu,
mbalkin@physics.oberlin.edu
Cc: dan@physics.oberlin.edu
Subject: triumph!
Alright, so perhaps it was a small
triumph. But some success was had creating and printing the test
files that we were all working on this afternoon (Friday). The following
are the lessons we have learned from this experience:
1) When using tvscl, you
have to specify units. Centimeters were what ended up working.
2) When using contour, it
is safest to use the default color table. Others will probably work,
but you have to be careful that the bottom entry in the color table isn't
white--then you will get blank pages, white printing on a white background.
3) Printing variables and
the like within a program can cause problems. We aren't sure yet
if using 'help' in the middle of a program is also dangerous, but if possible,
we should try to avoid using both help and print. Next week, maybe, we
can try to figure out whether help is a problem, and just how much damage
print does. The problem with print seems to be that it will print
the variable (array, etc.) to the current device, whatever that is, and
this can cause really bizarre things to happen.
4)Having the following line right
after set_plot, 'ps' was really important:
device, /color, bits_per_pixel=8
The /color thing isn't actually
necessary if you are using the default color table.
Kate
___________________________________________________________________
Date: Sat, 06 Jun 1998 00:20:53
-0400 (EDT)
From: Dan Stinebring <dan@physics.oberlin.edu>
Reply-To: Dan.Stinebring@oberlin.edu
To: Shon Martin <smartin@cs.oberlin.edu>
Cc: Team Pulsar 98 -- Jim Sheckard
<jsheckar@physics.oberlin.edu>,
Kate.Becker@oberlin.edu,
Mark.Kramer@oberlin.edu,
dan@physics.oberlin.edu,
Miranda.Balkin@oberlin.edu
Subject: psr4: printing problems
Shon,
This is an informational message only. We've got a problem that we need to track.
EVERYONE: save this message.
You will probably want to have it on hand if printing stops for you at
2am some morning. MOST IMPORTANT: if you run into a printing
problem and try to follow the 'lpc restart all' method indicated here,
notify me and Shon about what happened and whether or not you were able
to get printing going again. Include the time and the date and any
other details you think might be relevant.
Thanks, -- Dan
When using lpr from psr4 I found that the printer queue hung up at least twice this evening making it impossible to print.
In response to lpc status I got
psr4# lpc status
lp:
queuing is enabled
printing is enabled
3 entries in spool area
waiting for phhp5.physics.oberlin.edu to come up
postscript:
queuing is enabled
printing is enabled
no entries
no daemon present
[Note that it implies that phhp5 (the printer) is unreachable. The printer was showing a 'ready' message during this time. It was able to print its diagnostic pages and 'ping phhp5.physics.oberlin.edu' indicated that it was alive.]
I finally resorted to
psr4# lpc restart all
lp:
cannot open lock file [NOTE:
I think this is because I had previously removed
a 'lock' file in /var/spool/laser]
lp:
daemon started
postscript:
no daemon to abort
postscript:
daemon started
psr4# lpc status
lp:
queuing is enabled
printing is enabled
3 entries in spool area
waiting for phhp5.physics.oberlin.edu to come up
postscript:
queuing is enabled
printing is enabled
no entries
no daemon present
[Note that, at this point, it still appears that the problem exists. I then futzed around for a few more minutes. After a couple of minutes I tried 'lpc status' again, with the following result:]
psr4# lpc status
lp:
queuing is enabled
printing is enabled
no entries
no daemon present
postscript:
queuing is enabled
printing is enabled
no entries
no daemon present
[So, at this point all the old files had been removed from the queue and there was no more complaint about the printer not being on line. In fact, come to think of it, the 3 plots that had been queued up did come out, too.]
I don't know what to make of all this, but we need to watch it and report all problems to me and to you.
I have also found that everyone has permission to execute lpc:
-rwx--s--x 1 root 40960 Jul 23 1992 /usr/etc/lpc*
In our small group that is probably okay, but it is not 100% clear that
lpc restart all
is what got things going again.
Let's stay in touch about this problem.
-- Dan
Last Updated June 1998
