Skip to content

ENVI: ENVI software for processing and analyzing geospatial data

Overview of package

Package: ENVI
Description: ENVI software for processing and analyzing geospatial data
For more information: https://www.l3harrisgeospatial.com/Software-Technology/Enterprise-Solutions
Categories: SoftwareDevelopment
NumericalMethods
Visualization
License: Proprietary

General Usage

ENVI (ENvironment for Visualizing Images) is a software application used to process and analyze geospatial imagery. It is commonly used by remote sensing professionals and image analysts. ENVI, version 5.7, includes IDL (Interactive Data Language), version 8.9

This module will add the envi, idl and related commands to your path.

NOTE: If running on an HPCC and requesting less than all cores on a node, you should be setting IDL_CPU_TPOOL_NTHREADS environmental variable to be equal to SLURM_CPUS_PER_CORE for best performance; for more detail see https://hpcc.umd.edu/hpcc/help/software/envi.html#mthread

Available versions by cluster

This section lists the available versions of the package ENVIon the UMD HPC clusters.

Versions available on the Zaratan cluster

Version Module tags CPU(s) optimized for GPU ready?
5.7 5.7 x86_64 Yes

Although for short computations on a personal workstation the interactive mode of IDL is nice, sometimes one wishes to have IDL work in a batch-style mode. This is especially usefull for using IDL on the HPC clusters, where computationally intensive processes must be submitted to the scheduler for running on the compute nodes.

The easiest method is probably to invoke idl in batch mode on a simple script file which then uses the .RUN IDL executive command to run a main program file containing the real code you wish to run. I.e., create a main program file with the code you wish to run, e.g. the following would be a simple main program to print factorials, which we will place in a file called factorial_test.pro:

f = 1
max = 7
for k=1,max do begin
   f = k * f
   print, k, f
endfor
end

You should also create a simple IDL batch script to invoke this program, e.g. the batch_test.pro file below:

.run factorial_test.pro
exit

Warning

Be sure to include the exit command if you wish for IDL to terminate when the main program is finished. This is especially important when submitting jobs to the HPC cluster via sbatch, as otherwise you job will not terminate when the calculation is finished, but just sit at an idle IDL prompt until the wall time limit for the job is reached, wasting CPU cycles and charging your allocation account

You can then invoke your IDL code from the Unix command line with something like idl batch_test.pro (NOTE you can omit the .pro extension in the idl and .run commands if desired, as the .pro extension will be used by default.). To use with sbatch, a job script like

#!/bin/bash
#SBATCH -ntasks=1
#SBATCH -t 15
#SBATCH --mem-per-cpu=4000

source /etc/profile

module load idl

echo "Starting job ..."
idl batch_test
dd

The two separate .pro files are required in general because in IDL batch mode, which batch_test.pro runs under, each line is read and executed immediately. Control statements, e.g. the for loop in our factorial_test example, often span multiple line --- although you can use ampersands and dollar signs to continue lines, this quickly becomes messy. In main program parsing mode, such as is used for factoral_test, the entire program unit is read and compiled as a single unit. Since IDL code run in batch mode or submitted to the HPC compute nodes is assumed to be complicated, it is probably best to use this two file approach.

Multithreading and IDL

Recent versions of IDL support multi-threading, at least to some degree. This means that on systems with more than one CPU and/or mulitple cores per CPU socket, IDL will use multiple threads to do work in parallel when the application determines it is advantageous to do so. This is automatic, and invisible to the user except fora( hopefully) improved performance.

By default, when IDL encounters a calculation that would benefit from multi-threading, it will generate a thread for every CPU core on the system on which it is running. This is probably the desired behavior when IDL is the only (or the main) program running on a system, e.g. on a desktop or dedicated compute node.

But on many HPC systems, the available cores per node can be somewhat large (e.g. most nodes on Zaratan have 128 cores), and might be more than the optimal degree of parallelization for certain problems. On these systems, for certain problems, you might not wish to allocate all of the cores on the node to the calculation (since you will be charged for the time on those cores). However, if you restrict the number of cores with which your job is running, you must tell this restriction to IDL as well. Otherwise IDL will launch as many threads as the number of cores it detects on the system, which could adversely affect performance.

For example, let us assume that for the particular type of problem you are working on, you have determined (most likely through trial and error) that the greatest efficiency occurs for 6 cores. E.g. a 6 core job is 40% faster than a 4 core job, but an 8 core job is only a few percent faster than a 6 core job. So you submit a bunch of IDL jobs, each requesting 6 cores on a single node. Let us further assume that three of those 6 jobs start running on the same 128 core node. If you do not tell IDL to restrict itself to 6 cores, each of those IDL jobs might mistakenly think it has 128 cores it can use, and might break the calculation into 128 threads (for each job). In addition to any performance hits from splitting the calculation into too many pieces, you will also have 128 threads for each job running on the 6 cores available to the job, further degrading performance.

To tell IDL to use less than all of the cores it finds on the system, you need to set the IDL_CPU_TPOOL_NTHREADS environmental variable. By default, it is treated as 0, which means use all cores that can be found on the system. You should set it equal to the number of cores you requested from Slurm, typically SLURM_CPUS_PER_TASK. E.g.:

#!/bin/bash
#SBATCH -c 8 #Request 8 cpu cores on a single node 
#SBATCH -t 2:00
#SBATCH --mem-per-core=4000

source /etc/profile
module load idl

export IDL_CPU_TPOOL_NTHREADS=$SLURM_CPUS_PER_TASK

idl -e "myprogram.idl"

If you change the number of cores (the value after the -c flag), the environment variable SLURM_CPUS_PER_TASK will also change to that value, and so IDL_CPU_TPOOL_NTHREADS will also continue to be correct.