X
58 Rate this article:
No rating

INTERNAL: Getting Started With IDL: Important Concepts From a Recent New User

Zachary Norman

Introduction to IDL

This article is designed to give a first time user of IDL a brief description of how to start using the product based on personal experience of what information is really important to know. Some of these topics are from commonly asked questions by people who were also first time users and new to programming. The goal of this article is to provide a bare essentials introduction that will teach the reader about important concepts when programming in IDL, not necessarily the language or native functions/procedures. 

-The IDL Development Environment (IDLDE)
- File naming conventions
- IDL path management
- Useful facts about the IDL programming language
- Types of IDL programs and memory Scope
- Writing a simple procedure, function, and main level program
- Where to look for additional information

The IDL Development Environment (IDLDE)

Before learning about the details behind IDL, it is important to know about the IDLDE, or sometimes called the IDL Workbench. As a quick introduction, a link for the online documentation specifically describing the IDLDE is provided below. This is important to review first so that certain terms will be familiar like the IDL Console and Editor window. 

http://www.exelisvis.com/docs/IDLDEOverview.html

Apart from that link, below is a screenshot with the most important areas boxed in red. See the link for more information on each section. 



File Naming Conventions

NOTE:  If you do not follow the IDL naming convention then you will likely get errors regarding files not being found or functions/procedures not being recognized . A short example of this is provided. 

One of the most important facts to know about when learning how to use IDL is the naming convention. When first starting out, I would recommend that each separate function or procedure get a separate .pro file which mimics the name. In other words, if you have a procedure called “my_pro” then the corresponding .pro file should be named “my_pro.pro”. The main reason for this is that when you type “my_pro” into the IDL Console, then IDL searches automatically for a .pro file which is named “my_pro.pro”. If you don’t name your .pro file the same as the function/procedure name, then you may get an error similar to:

IDL> my_pro
% Attempt to call undefined procedure: 'MY_PRO'.
% Execution halted at: $MAIN$

For you to test this and see how IDL automatically wants to name files, click on the “New Pro” button near the top left of the IDLDE. Once a new window has popped up in the editor, copy/paste the following code into the blank file and then save the file. Leave the default destination and name the same as appear in the save dialog. It is worth noting that IDL automatically wants to give the .pro file the same name as the function/procedure which should be followed. Here is the code to save:

pro my_pro
    print, 'My awesome test procedure!'
end

Now, to use it, you type “my_pro” in the IDL Console you should now get:

IDL> my_func
% Compiled module: MY_FUNC.
My awesome test function!

To see how this breaks when the naming conventions are not the same, change the code in the “my_pro.pro” file to:

pro my_pro2
    print, 'My awesome test procedure!'
end

Once you have done this, press the “Reset” button near the top of the IDLDE and then type “my_pro2” into the IDL Console. You should see something like:

IDL> my_pro2
% Attempt to call undefined procedure: 'MY_PRO2'.
% Execution halted at: $MAIN$    

Make sure to change the name of the procedure back to “my_pro” before going to the next step. A good rule of thumb for naming files is to NOT include spaces in your .pro file names and use the underscore character instead. It is also important to only use lower-case characters in your .pro file names. This is because if you are using Linux, then the OS may not like when upper and lower case words are included. This can apply to Mac as well. There are also other reasons that IDL may not find your files, which is why it is good to know a little bit about path management as well.



IDL Path Management

Managing your IDL paths is fairly straightforward, but can cause errors with files not being found. In order to add folders to your path, go to Preferences->IDL->Paths. The image below shows what your preferences page should look like.


From here, if you select the insert button, then you can add a new folder/directory to the search path. When you include this option, continuing with the example above with a .pro file named “my_pro.pro”, IDL will search through each listed directory for the “my_pro.pro” file in addition to the default path. There are three other preferences on this page that are important to know.

First, if you include a new folder/directory to IDL’s search path, there will be the option to include subdirectories. This can be a handy option, but if your file contains many different subdirectories, then it can take IDL longer to initialize and search for different files. 

The second important setting to notice is the option to “Move up” or Move down” additional search directories. This is important because you can alter the order than IDL follows to search for a particular .pro file.  It is recommended that you keep the <IDL_DEFAULT> path as the first search directory, and only manage you additions. This is because if you create a routine with the same name as a native IDL routine, and <IDL_DEFAULT> is not the first search location, then you could start using the wrong function/procedure when you do not mean to. 

The last important setting to note is the check box  that says “Warn when a routine is on IDL’s path more than once.” This is important to let you know that you gave a file a name which has already been used. You can get an error similar to what was referenced in the previous paragraph. If you do have duplicate routines, then one place that you can look is the “Problems” tab by the IDL Console in the IDLDE. From here, the next step is to know some of the technical aspects to using IDL. 


Useful Facts About The IDL Programming Language

One of the nicest aspects about IDL’s programming language is that it is case insensitive. This means that IDL will interpret two command the same if one is all capital letters or if one is all lower case. A good example of this is the following, which you can type directly into the IDL Console:

p = plot(/test)
p = PLOT(/test)

It is a good idea to adopt your own convention, to be consistent, with how you reference IDL functions when programming. Personally, I like to use all lower case letters for all of my programming, but it is up to the user to decide that. Another great aspect of IDL is that, in general, it is backwards compatible.

What backwards compatible means is that code written n much older versions of IDL should also work on newer versions of IDL. Generally, this is always the case, but sometimes there are functions which are removed from IDL that will not work the same or at all. This can be a useful component to IDL when using graphics because there are two types: old “direct graphics” and new “function graphics.” 

Another great functionality in IDL is that IDL automatically compiles files for you if:  1) you reference the function/procedure that corresponds to the name of the .pro file and 2) the .pro file is located within IDL’s search path. Continuing with the example using “my_pro.pro” you can compile (and run) the file by typing in “my_func” to the IDL console as below:

IDL> my_func
% Compiled module: MY_FUNC.
My awesome test function!

If you decide to make changes to your .pro file after it is compiled, then you will need to re-compile the function. To do this, you can either press the “Compile” button near the top of the IDLDE or you can type something like ”.compile my_pro” in the IDL Console to manually compile. From here, it is a good idea to talk about the different types of IDL programs and the memory scope associated with each one.




Types of IDL Programs and a Short Intro to Memory Scope

For IDL, there are three important types of programs which all have their own memory scope. These are: main level programs, procedures, and functions. The first one that we will discuss is the main level program. These programs are in .pro files and do not contain a “pro” or “function” declaration in the file. However, all main level programs must end with an “end” statement. Below is an example of a main level program that defines a variable called “temp” and prints the output to the IDL Console. To run this example, create a new pro file (which can have any name because it does not contain a procedure or function definition) and press the “Run” button in the IDLDE near the top of the screen. 

temp = 5
print, temp
end

The output from running the main level program should be something like:

% Compiled module: $MAIN$.
       5

Another thing to note is that when you define a variable in a main level program, then the variable is known to all main level programs and can be called from the IDL Console. You can confirm this by looking in the Variables tab of the IDLDE and should look like the screenshot below.


The next type of program in IDL is the function. Functions are similar to procedures, but they should have a line which has “return” to return a value. Any code that appears after the line which contains “return” will not be executed. If the “return” statement is left out, then a zero will automatically be returned from the function. Below is a small test function to illustrate how to call a function.  This should be saved as “my_func.pro” and can be called by typing “my_func(5)” in the IDL console.

function my_func, number
    ;make sure to only enter numbers
    temp = number
    return, 'You entered ' + strtrim(string(number),1) + ' as a function input'
end

As a little background on the function, string(number) converts the number to a string format and strtrim(string(number),1) removes any spaces within the string. It is important to note that the variables tab will be empty, even though the variable temp is defined within my_func. This related to the scope of the program. The variables within functions and procedures will not automatically exist outside of their parent function/procedure. If you check the Variables tab after calling my_func, then the variable “temp” will not be shown. In the same manner, you cannot automatically call a main level program variable from a function or procedure. 

To see an example of how to create a procedure, look under the section “File Naming Conventions” above. The main difference between procedures and functions is that procedures step through their code and are not required to return a value whereas functions are required to return a value. A return statement can be used in a procedure, but it cannot be used to return any value. The next example is going to include aspects of all three programs to illustrate how they can be used together. 

One of my favorite things about IDL is that you can combine procedures and main level programs all in the same file. To see this, create a new .pro file which contains the following code and should be named “test_plot_procedure.pro”

;define the function
function test_plot_procedure
    p = plot(/test)
end

;main level program which only needs
;an end statement
print, 'Main level Program'
print, 'Creates a plot of test data'
test_plot_procedure
end

You can run this by pressing the ‘Run” button at the top of the IDLDE. This code will create a plot window with test data plotted and print a few lines to the IDL Console.


Where to Look For Additional Information

Apart from this help article, there are many places that you can look for additional information on how to use IDL. Each installation of IDL has a local help session which can be accessed by typing a question mark in the IDL console or by selecting help contents from the Help menu. My personal favorite is to go to the Exelis VIS website (http://www.exelisvis.com/Support.aspx )and search for items there. I use the search bow in the upper right corner of the screen. This is the most comprehensive search because it return documentation pages, help articles, and forum posts. There is always the option to contact technical support directly and seek assistance.

If you would like direct help from the folks at technical support, you will need to be current on maintenance and not on our new Academic Support Policy. For more information on what is included in product maintenance, see the following link:
http://www.exelisvis.com/portals/0/pdfs/Exelis_VIS_North_American_Maintenance_Program.pdf 

This link describes the difference between Academic Support and typical technical support offered to those customers who are current on maintenance.
http://www.exelisvis.com/Support/HelpArticlesDetail/TabId/219/ArtMID/900/ArticleID/14138/Exelis-VIS-Technical-Support-Policy-Updates.aspx