This function computes the X-ray mass absorption coefficient for a
given element, based on the NIST mass absorption coefficients.
These tables are most well sampled for energies between 1 keV and
100 MeV. These coefficients are from the tables at:

The user specifies the atomic elements, either by the atomic symbol
(as a character string), or by the atomic number (Z).
The transmission of a medium is then defined by:

TRANS = EXP(- MU_RHO * RHO * THICKNESS )

where MU_RHO is the value returned by this function (cm^2/g), RHO
is the mass density of the medium (g/cm^3), and THICKNESS is the
thickness of the material (cm). All cross section data are stored
within the source code file (in a compressed form, translated
unchanged from the NIST database).

CMUNIQUE_ID returns a "unique" 8 character identifier.
Programmers can use this routine to derive unique strings which
can be used to write files, etc.

Identifiers are "unique" in the sense that it is unlikely that two
identifiers in a given IDL session will coincide. Thus the
identifier is useful for constructing temporary filenames and
other hash values. User routines are encouraged to append other
identifying information to this string, such as a session id, a
hostname, or a process id number.

Command line debugging with IDL has always been difficult. It does
provide excellent abilities to interactively query and set variables,
but only at one level -- the deepest level. Generally, when debugging
a larger suite of programs one can have procedures and functions that
nest several levels deep. Since one procedure can call another, or
even itself, this is a natural effect. If an error occurs in a
procedure several levels deep, knowing the values of variables at
higher levels (i.e., the calling routines) can be useful and time
saving. Unfortunately IDL has no documented provisions for doing
this.

The procedures in the package supply convenience routines for
navigating up and down the IDL call stack (DXUP and DXDOWN); for
interogating and modifying IDL variables at any levels in the call
stack (DXHELP, DXPRINT, DXGET, DXSET); and for quickly setting and
clearing breakpoints (DXBREAK, DXFINISH and DXCLEAR). The package is
based upon invaluable discussions about the undocumented
ROUTINE_NAMES() function on the comp.lang.idl-pvwave Usenet newsgroup.

Please read DXREADME, which contains general instructions on how to
get started degugging.

CMSYSTIME serves two functions. It computes the current time in a
fashion similar to the built-in IDL system function SYSTIME(). It
also can convert between various time representations and systems,
including a textual format.

The current time can be obtained by invoking CMSYSTIME with the
/NOW keyword (which is entirely equivalent to SYSTIME(1)).

The most substantial part of CMSYSTIME, which distinguishes it from
SYSTIME, is its ability to convert between different time formats.
CMSYSTIME recognizes can recognize and convert between time in seconds
(seconds since Jan 1, 1970 [ = SEC ]) and days (Julian days [ = JDAY ]
or "Modified" Julian days [ = MJD = JDAY - 2400000.5 ]). It can also
recognize and convert between local and GM time. The local time zone
is determined automatically.

CMSYSTIME takes maximum care to preserve the full numerical
precision of the time values. It converts all values to double
precision and may return days and seconds with fractional parts.
CMSYSTIME accepts one parameter, the input time to be converted.
Unlike SYSTIME, the *function* of CMSYSTIME is governed by various
keywords, as summarized in the following table:

I find this routine very useful on Unix systems for performing
continuous status updates during long calculations. This routine
performs a similar function to the "percentage completion" status
widget that you often find under Windows or MacIntosh.

STATUSLINE interacts directly with the terminal console to perform
character addressing, which must be VT100, XTerm, ANSI, or compatible.

This is a modified version of CONGRID.PRO, supplied in the IDL
distribution. The original CONGRID does not handle the edge
conditions properly, either with or without the MINUS_ONE keyword. The
problem is noticeable when small images are resampled to be very large
images, since an "extra" column and row is added at one side
of the image. With the MINUS_ONE keyword, a coordinate grid cannot be
properly overlayed.

This version can be used in place of the original CONGRID, and
defines a new keyword called HALF_HALF which does the correct
interpolation. "Half" of an extra row and column are added
to both sides of the image, making it properly symmetric. A
coordinate system can also be overlayed correctly. TVIMAGE is a
slightly modified version of David Fanning's procedure, which takes
advantage of the new CMCONGRID.

I assert that the output of CMCONGRID with the HALF_HALF keyword is
always more correct than that of CONGRID alone. And now,
with a bug fix from Wayne Landsman, it's even more correct!
The correction is most apparent when down-sampling.