IDL is commercial data visualization software; NICS pays annual maintenance for a pool of license available to UCO/Lick users, and many users have licenses that are locked to individual machines (typically laptops).
IDL on NICS-managed UNIX hosts
To get started using IDL, you first need to adjust your environment; the IDL environment variables are not enabled by default. If you are a csh or tcsh user, you want to modify your .cshrc file in your home directory; if you are a bash user, you want to modify your .bash_profile. For example, in the default .bash_profile, there are a pair of lines that read:
#### For IDL users # source /opt/idl/bin/idl_setup.bash
You want to uncomment the second line. Once you have done this, log out of your session, log back in, and the standard IDL executables (such as idlde) should now be available to you on the command line.
IDL on other UCO/Lick hosts
If you are on the UCO/Lick network (either at UCSC or at Mt. Hamilton), you may make free use of our central pool of licenses. Note that you can only do so if you have uninterrupted direct network contact with the central license server. There are two ways to access our central license pool; the first method will affect all users using a specific IDL install, the second will affect only an individual user.
To configure IDL for all users on a specific computer, you should edit the license.dat file associated with your IDL installation. Here is a breakdown of default locations for this license.dat file:
Operating System: |
Filename: |
MacOSX |
/Applications/rsi/license/license.dat |
Linux |
/usr/local/rsi/license/license.dat |
Windows |
|
You want that file to look like this:
####################### LICENSE.DAT ####################### ############ license file comments, do not delete ############### # License Number(s): 207564-1 207564-10 207564-16 207564-22 # 207564-3 220905 97451-1 SERVER license.ucolick.org 808dfe82 1700 USE_SERVER ##################### end of license file ####################### ###########################################################
The second option, which only affects one user at a time, is to set the LM_LICENSE_FILE variable in your local user environment to be:
1700@license.ucolick.org
To make that change permanent, be sure to edit your .bash_profile or .cshrc file such that this environment variable is established every time you log in.
Using IDL from outside UCO/Lick
NICS does not support the use of the central IDL license server from home, but no prohibitions are made against doing so. In other words, if you can figure out how to make it work, you are welcome to do so, but NICS cannot help you accomplish this.
The simplest way to run IDL from home is to ssh into a host on the UCO/Lick network, and run IDL on the server. Another option is to purchase a node-lock license for use either at home or on a laptop. Using a node-lock license will also allow you to use IDL in situations where you have no network connectivity of any kind.
It is possible, however, to set up ssh tunnels to forward the license requests and have your IDL session at home successfully acquire a license. You need to forward two tcp ports from your home computer to license.ucolick.org: 1700 and 52398. You will need to set up the ssh tunnels via ssh.ucolick.org. Once you forward those two ports, configure your environment as described above for hosts on the UCO/Lick network, with the exception that you need to point the license server to your home computer. Ssh takes care of getting the network packets to mambo and back.
To accomplish the port forwardings, run this:
ssh -f -N -L1700:license:1700 -L52398:license:52398 ssh.ucolick.org
-L1700:mambo:1700 means "take anything sent to port 1700 on my computer, send it over the ssh connection, and then send it to port 1700 on license.ucolick.org." Similarly for the other -L argument.
-f means "put ssh in the background after it asks for passwords"
-N means "don't log in or run a command once the ssh connection is established. Just forward ports."
Now, IDL needs to know how to find the license server. Run one of the following (one will work and the other will give you an error, depending on wither you use bash or csh):
export LM_LICENSE_FILE=1700@localhost setenv LM_LICENSE_FILE 1700@localhost
Note that by saying "localhost" we're directing IDL to look for the license server on port 1700 of your home computer! So, IDL tries to find the license server on port 1700 of your computer. Ssh sees the request and ships it over the ssh link then redirects it to port 1700 on license.ucolick.org. The actual IDL license server then gets the request and responds, with the responses following the reverse course back to IDL running on your home computer. Similarly for traffic on port 52398.
NOTE: The high-end port number can change each time NICS "bounces" the IDL license server. If it does, this pages gets updated as part of that process. So if your tunneled IDL license connection stops working, look HERE to get the new port number.
This procedure worked for GregNovak as of June 7, 2007.
IDL's stored configuration files
IDL may store modified configuration variables within your local user directory. Look for a directory that looks like:
.idl/rsi/pref-10-idl_6_2-unix/idl.pref
CMYK plots
Courtesy of Mike Kuhlen
set_plot,'ps' device, /cmyk
IDL Search Path
Courtesy of Scott Seagroves
My .bash_profile has in it:
export IDL_PATH="+${HOME}/idl:<IDL_DEFAULT>"
of course you can put anything you want in there instead of $HOME/idl, but here are the important parts:
- The "+" sign tells IDL to search subdirectories of $HOME/idl, so if you did export IDL_PATH="+/some/path/to/my/programs" it would find IDL routines in all subdirectories of /some/path/to/my/programs
<IDL_DEFAULT> is, well, the default IDL path. Putting it last means I can write routines with the same names as IDL routines and mine will be found first. This is occasionally useful, and just as occasionally causes me trip-ups. Your mileage may vary.
Neither of these are bash features; it's IDL that looks for the "+" and the <IDL_DEFAULT>, so don't think you can use this handy notation for other path variables
Saving plots to graphics files
It's easy to save IDL plots as Postscript files, but sometimes you want to make image files, for example if you are generating graphs for a web page. It's possible to convert the Postscript file to an image, but it's easier to do it straight from IDL. The Z buffer device works well for this. Put
set_plot,'z'
in your program, and then use this function to save the current plot to an image:
pro save_plot,filename print, "Saving image" + filename a=tvrd() tvlct,r,g,b,/get write_png, filename,a,r,g,b end
Note: You can also do this with the default X Windows device, however in that case the image is stored on the X server, i.e. on the machine you are sitting at. Since this is not necessarily the machine you are running IDL on, reading back the pixmap is a lot slower than using the Z buffer device. (You can try just by using the above save_plot function, but you need to use a Pseudocolor visual so do
device,pseudo_color=8
before plotting anything.)
Making density plots instead of scatter plots
If you are making scatter plots with many, many points, they all start covering each other and you can't tell where the density is highest. You need a color plot instead. This little routine makes it for you:
pro make_2dcolor,x,y,nbinx,nbiny
; x,y contains points to be made into a color density plot
datax=!X.CRANGE
datay=!Y.CRANGE
; check if axes are flipped, in that case we have to fix because
; hist_2d will choke
if datax[1] lt datax[0] then begin
sx=-datax
x=-x
end else $
sx=datax
if datay[1] lt datay[0] then begin
sy=-datay
y=-y
end
else $
sy=datay
d=hist_2d(x,y,min1=sx[0],max1=sx[1],bin1=(sx[1]-sx[0])/nbinx,$
min2=sy[0],max2=sy[1],bin2=(sy [1] - sy [0])/nbiny)
; get device coordinates of plotting region
devmin = convert_coord([datax[0],datay[0]],/data,/to_dev)
devmax = convert_coord([datax[1],datay[1]],/data,/to_dev)
; rebin data to req # of pixels
h=congrid(d,devmax[0]-devmin[0],devmax[1]-devmin[1])
; display it
tvscl,max(h)-h,devmin[0],devmin[1]
end
(What is not straightforward is getting the image up in the plotting area with the correct axes.) Because this routine uses the current plotting range it needs to be set, and the only way I know how to do that is to actually plot. Unfortunately, displaying the image will delete part of the axes, so after calling this routine it's necessary to replot the axes using the /noerase keyword. Don't forget to load a color map first. (By the way, if you are plotting using X, I can't vouch for this working under TrueColor, because of the way the colors work. Use
device,/pseudo_color=8
to set PseudoColor (color map) mode before plotting anything.)
Portable plot labels with TeXtoIDL
As described by Mike Kuhlen, IDL PostScript plots using TrueType or vector fonts are vastly larger than those using device fonts, so when making PostScript plots, you want to use device fonts (!P.FONT=0). However, I like the vector fonts for screen display, especially if you using 256 color output, because in that case the TrueType fonts can't do antialiasing and they look bad.
In this case, the problem is that to get the Greek characters, different control sequences are used for device fonts and vector fonts. Major pain... (Incidentally, the sun symbol is also different.) TeXtoIDL comes to the rescue. It's a package that provides translation from TeX to IDL format strings, so instead of writing 'L!D!7k!X!N' or 'L!D!Ml!N' (for the two different types of fonts), you do textoidl('L_\lambda'), and it gets translated to the correct formatting sequence for the current type of fonts.
Incidentally, the IDL astro library also defines the function sunsymbol(), that gets translated to the appropriate way of making the sun symbol. (Unfortunately, textoidl doesn't understand \odot...)