IDL


Thumbnail of DocBook output I have the framework in place to have IDLdoc produce output besides HTML. This has been a long process beginning in IDLdoc 2.0 when I switched to using templates instead of embedding the HTML code in the IDL code. I have started by writing a set of templates for DocBook output, but intend to write a LaTeX set as well.

Here’s an example PDF of IDLdoc output for a library of routines for visualization I’ve been thinking about.

lic_thumb.png While producing some flow visualizations lately, I've found that smoothing a random texture gives less pixellated looking result than using a purely random texture. I added a texture keyword a while ago so that a common texture could be used for several LIC images, but now I've discovered that playing around with the texture a bit can be useful. I've been creating the texture with:

IDL> r = randomu(seed, xsize, ysize)
IDL> t = bytscl(smooth(r, 3, /edge_truncate))

Click on the thumbnail image to see the full image.

I just released IDLdoc 3.1 (see full release notes are below). As per this short blog post, IDLdoc is getting integrated into the IDL Workbench. This release adds some rst markup features that the IDL Workbench will use -- my favorite is to be able to link to images with:

.. image:: filename

IDLdoc will link to the image and also copy the image file into the output directory (if OUTPUT keyword to IDLDOC routine is used).

  1. Added ability to reference images in rst markup. IDLdoc will automatically copy referenced images into the output.
  2. In rst markup, illegal characters like < and > are automatically converted to character entities.
  3. Added `:Description:` tag for compatibility with IDL Workbench update.
  4. Changed default markup parser to rst when format parser is rst.
  5. Miscellaneous small bug fixes.

IDLdoc support will be added to the IDL Workbench in an update planned for June. This will add some really cool features for those who use IDLdoc and the Workbench:

  1. enhanced hover help on routines with an IDLdoc header
  2. content assistant on tag names when writing IDLdoc comments
  3. menu item and keyboard shortcut to insert an IDLdoc routine or file header (and preferences to define what tags you want inserted)

The Workbench will recognize comments in the rst format.

There will be an IDLdoc 3.1 release any day now to add some features necessary to support this and fix a couple bugs.

I have not been a big fan of the online help in the IDL 7.0 Workbench, but one feature I have been using regularly is the "Send us a comment on this topic" link at the bottom of every help page. Now I click it for every problem in the documentation I see. It doesn't have the same immediate effect that a Wiki would, but it has a similar feel when I get the response back that it's fixed and I will see it in the next version. Hopefully, others are doing the same (hint, hint).

In this recent IT Conversations interview, Jon Udell discusses topics from Greg Wilson's recent talk "High-Performance Computing Considered Dangerous". Wilson places a new emphasis on testing and usability over more power and speed.

The interview focused on the difficulties of learning techniques in High-Performance Computing and, in general, about the split between scientific computing and "commercial" software development. Tools have to improve because there is no more time in the science curriculum to teach science graduate students more about software engineering practices. In particular, I thought the comments about version control aiding in the reproducibility of computations were interesting (version control as a "software lab notebook"). He also mentions that tools like "Matlab, IDL, and Mathematica" are scoffed at by the HPC gurus, but are the tools that many scientists are using to solve their problems (he put Excel in a category of popularity above these). Our focus should be adding easy to use HPC techniques to these platforms.

David Fanning made some fixes to the Brewer color tables addressing the issues reported in the comments of the last update by Philippe Le Sage. The update includes the following:

  1. Fixing values in sequential and diverging color tables.
  2. Fixed up names of diverging color tables
  3. I also realized that it was unnecessary to include multiple versions of each of qualitative color table because the one with the most colors is a superset of the other versions.

See the last update for routines to access these color tables.

Thanks David and Philippe!

I just received a copy of IDL Primer by Ronn Kling. (Full disclousre: I received a free copy because Ronn used my Periodic Table of IDL Operators on the back cover.) It's a pocket sized “quick reference” that provides a quick introduction to the main functional areas of IDL: the IDL Environment (DE is covered, get Kling's Navigating the Workbench for coverage of the Workbench), syntax, array operations, program flow, 2D and 3D graphics, image processing, object graphics, file I/O, mapping, and animation. I have found it to be a quite handy reference, particularly the list of “Important Routines by Function” at the back (similar to the Functional List of IDL Routines in the online help).

Yee electric field frame 252 I have finished the line-integral convolution (LIC) implementation as a DLM and cleaned it up a bit (see other articles for background). More work is needed, but it can give useful results now. The movie at the right took about six minutes to generate (300 calls with 300 by 300 images).

The API for the call is pretty straightforward. There are two required positional parameters u and v which are m by n float arrays (they must be float arrays right now). There is one optional keyword texture which can be set to a byte array the same size as u and v. It is useful to set texture to the same array for frames of a movie; there will be a lot of jitter if you don't.

Installation is slightly more complicated than for IDL code. Grab the zip file, unzip it, and place the contents in the IDL path and the IDL DLM path. Start IDL and type:

IDL> vis_build_flow

You should be ready to go as long as your !make_dll system variable is set correctly (which is probably the case on normal Unix platforms, but only if you have installed the Developer Tools on Mac OS X or Visual Studio on Windows). I would be interested in people's experiences trying to install this since I haven't distributed a DLM on this site before.

I am going to package some visualization routines together with the vis prefix, but I'm waiting until I have a critical mass of useful routines before distributing the whole thing.

UPDATE: by the way, if you use vis_lic and can share your results, I would like to see any images made with it.

There are mechanisms in the IDL Workbench (or the old IDLDE) to set the IDL !PATH, but I have not found them useful. I have a somewhat byzantine system to set my path, but it works well for me. Since there has been discussion on the newsgroup recently about problems others are having, I thought I would write up my method.

My requirements for setting the path:

  1. I need to be able to control exactly what appeared in my path. It needs to be clear what is currently in the path and easy to change what will be in the path the next time I start IDL. I don't need to be able to change my path while using IDL (though I think my solution could be used for that too).
  2. Directories with subdirectories containing code (i.e. using +) should still appear as a single entry.
  3. Needs to work for both the command line and the Workbench.

Continue reading "Path management."

« Previous PageNext Page »