You need to be running from a window that is capable of displaying IRAF graphics and have the window type properly identified in the CL. If you are running IRAF in a workstation environment then check to be sure that you are running IRAF from either an XGterm or an XTerm window. Other terminal emulators (such as cmdtool, rxvt, aixterm, etc) on your desktop do not support graphics.
The next step is be sure you have the value of your terminal type set correctly.
cl> stty # reports current settings cl> stty xgterm nlines=### # for XGterm cl> stty xterm nlines=### # for XTERM, status line in # graphics window cl> stty xtermjh nlines=### # for XTERM, status line in # text window cl> stty vt640 # for retrographics terminal
Look at the dev$graphcap file for other valid terminal types if you are using a standard terminal and not a workstation.
They are identical except for the location of the status line, the single line used within graphics applications for user input. With xterm, this line is written in reverse video at the bottom of the graphics window. Since xterm can't erase and overwrite this line, the status line is written to a new location within the graphics window each time it is used, consuming window space until the window is redrawn. The xtermjh terminal type writes the status line to the text window, leaving the graphics window entirely free of status line i/o. Most people using tasks that make even moderate use of the graphics status line prefer the "xtermjh" setting.
The AIXterm window is not a supported graphics terminal emulator, users should use an XTerm window instead. This requires that the X11rte.obj product be installed (use the "lslpp -l" command t verify this). Another possible source of confusion is the fact that /usr/bin/X11/xterm is a symbolic link which could be pointing to the aixterm executable. If so this link should be reset so it points to /usr/lpp/X11/Xamples/bin/xterm. If a graphics task results in garbage being written to the screen it is usually a sign that the wrong terminal emulator is being run.
No, we have a workaround for this frequently encountered limitation. By default, there is a single set of fifo pipes in /dev used for communication with the DISPLAY task, limiting the number of successful SAOimage processes to one per cpu. (See IRAF Newsletter #11, April 1991, "Setting up Multiple Fifo Pipes for [V1.02] SAOimage".) However, SAOimage allows the user to specify a set of personal fifo pipes to be used instead of the ones in the system /dev directory. For multiple SAOimage processes to run per CPU, the user must create personal pipes and define the paths to these new pipes in a private copy of graphcap as described below.
To create the personal pipes and graphcap file it is suggested you create a subdirectory of your iraf login directory named 'dev' in which to put the files. A sequence of commands such as the following should be all that is needed (note the location of the 'mknod' command may differ, on some systems the 'mkfifo' command is preferred): % cd ~/iraf # create the 'dev' subdirectory % mkdir dev % cd dev % /usr/sbin/mknod imt1i p # create the fifo pipes % /usr/sbin/mknod imt1o p % chmod 600 imt1o imt1i % sed s+imtool,,+imtool,$cwd/imt1,+g $iraf/dev/graphcap > mygraphcap The last command edits a personal copy of the graphcap file.
To start up SAOimage with the "new" fifo pipes, use the following command with appropriate pathname substitutions. Note that the "idev" to SAOimage is the imt1o pipe (the SAOimage input is the DISPLAY task output): % saoimage -idev /mydir/dev/imt1o -odev /mydir/dev/imt1i &
To direct the CL to use your private copy of graphcap, put this line in your loginuser.cl file: set graphcap = home$dev/mygraphcap
Note that the "saoimage" command above is valid for V1.07; earlier versions of SAOimage require a "-imtool" inserted before the &.
It is possible for a user to have multiple SAOimages running. This situation is not the same as multiple users each running SAOimage on the same CPU. That was addressed in an IRAF Newsletter article (INL #11, April 1991, "Setting up Multiple Fifo Pipes for SAOimage") which is included in the prev- ious entry of this FAQ listing. There are similarities between the two scenarios, so you should understand the NL article before continuing with this discussion. We assume you are running v1.06 or v1.07 of SAOimage. Say a user wants to have 2 SAOimage windows running and be able to display to them independently from a CL session. For each SAOimage process, the user must provide the following 4 items: fifo pipes, saoimage aliases, dev$graphcap modifications, and a private imtoolrc file. In this example, two SAOimages are defined, each recognizing 3 frame buffer sizes.
1) Create the fifo pipes, perhaps in /mydir/dev/devices where /mydir/ refers to the login directory of the user in this and the following items. I will name the pipes imt1i, imt1o and imt2i, imt2o:
% cd % mkdir dev % cd dev
% /usr/sbin/mknod imt1i p % /usr/sbin/mknod imt1o p % chmod 600 imt1o imt1i
% /usr/sbin/mknod imt2i p % /usr/sbin/mknod imt2o p % chmod 600 imt2o imt2i
2) Define two aliases for saoimage, specifying the personal pipes created above, perhaps in a .cshrc file (with idev, odev as defined above):
% alias saoimage1 'saoimage -idev /mydir/dev/imt1o -odev /mydir/dev/imt1i &' % alias saoimage2 'saoimage -idev /mydir/dev/imt2o -odev /mydir/dev/imt2i &'
3) For each frame buffer size, make an entry in dev$graphcap with a unique name and proper fifo pipe specification in the DD string. As the NL article recommends, copy dev$graphcap into /mydir/dev/mygraphcap and add a "reset graphcap = home$dev/mygraphcap" statement to your login.cl file. In these sample graphcap entries, stdimage devices imt1, imt2, and imt3 use the imt1 fifo pipes with frame buffer sizes 512, 800 and 1024 square respectively. The devices imt61, imt62, and imt63 use the imt2 fifo pipes with frame buffer sizes 512, 800, and 1024 square.
imt1|imt512|imtool|Imtool display server:\ :cn#1:LC:BS@:z0#1:zr#200:\ :DD=node!imtool,/mydir/dev/imt1,512,512:tc=iism70: imt2|imt800|:cn#2:xr#800:yr#800:\ :LC:BS@:z0#1:zr#200:\ :DD=node!imtool,/mydir/dev/imt1,800,800:tc=iism70: imt3|imt1024|:cn#3:xr#1024:yr#1024:\ :LC:BS@:z0#1:zr#200:\ :DD=node!imtool,/mydir/dev/imt1,1024,1024:tc=iism70:
imt61|imt512a|imtool|Imtool display server:\ :cn#1:LC:BS@:z0#1:zr#200:\ :DD=node!imtool,/mydir/dev/imt2,512,512:tc=iism70: imt62|imt800a|:cn#2:xr#800:yr#800:\ :LC:BS@:z0#1:zr#200:\ :DD=node!imtool,/mydir/dev/imt2,800,800:tc=iism70: imt63|imt1024a|:cn#3:xr#1024:yr#1024:\ :LC:BS@:z0#1:zr#200:\ :DD=node!imtool,/mydir/dev/imt2,1024,1024:tc=iism70:
4) Corresponding to each graphcap entry, make an entry in imtoolrc. SAOimage looks for a user imtoolrc file defined in your environment (setenv imtoolrc or setenv IMTOOLRC), and if that's not found, ~/.imtoolrc is used. If that's not found, /usr/local/lib/imtoolrc is used; imtoolrc was copied into this directory from dev$imtoolrc by the install script. So copy the original imtoolrc file in ~/.imtoolrc (for example) and edit it to include the following entries (entries 1-3 are unchanged from the original file):
1 2 512 512 # imt1|imt512 2 2 800 800 # imt2|imt800 3 2 1024 1024 # imt3|imt1024
# User added formats. 61 2 512 512 # imt61|imt512a 62 2 800 800 # imt62|imt800a 63 2 1024 1024 # imt63|imt1024a
SAOimage allows only 64 frame buffer configurations. XImtool allows more and the distributed imtoolrc file has more than 64 entries. To add your new entries, you'll have to clobber some of the first 64 entries and replace them with your own. In this example, I redefined imt61-63.
And, that's all there is to it! Start up saoimage1 and saoimage2, login to the CL (with your graphcap redefined) and try displaying to imt1 and imt61. One thing to watch for in debugging this is "zombie saoimage processes". If you interrupt the DISPLAY task with ^C and certainly in other ways, you can end up with an SAOimage process running without a connected window. If you try to display and you get no output and no error, this may be the cause. Use "ps -aux" to find the process and then kill it.
This usually indicates a missing or insufficient definition for the LD_LIBRARY_PATH host environment variable. For example, on a Sun system this may be set to simply '/usr/openwin/lib', but if the application in question was compiled under the local X11R5 system the missing shared object may be in /usr/lib/X11 (or some other path). In rare cases the missing object is in the compiler directory (e.g. in /usr/lang/SC1.x under SunOS). To find out where the missing file is and reset the LD_LIBRARY_PATH variable appropriately, try the following:
% echo $LD_LIBRARY_PATH # see what the current setting is /usr/lib/X11 % ldd `which saoimage` # check dependencies -lX11.4 => /usr/openwin/lib/libX11.so.4.3 -lc.1 => /usr/lib/libc.so.1.7.3 -ldl.1 => /usr/lib/libdl.so.1.0 % setenv LD_LIBRARY_PATH /usr/lib/X11:/usr/openwin/lib
This last command reset the variable so both /usr/lib/X11 and /usr/openwin/lib are searched for the needed file, the command should run normally after that, the directories /lib, /usr/lib and /usr/local/lib are searched by default.