One of the features I’m most excited about in GPULib 1.6 is the ability to create your own kernel and call it from within the GPULib framework. Details and an example are on the GPULib blog. This feature requires CUDA programming knowledge, but makes it much easier to integrate custom CUDA code into IDL.

You can download a free version of GPULib which has basic features and includes a short term license for the full features of GPULib as well. Calling custom CUDA kernels requires the full version of GPULib.

Full disclosure: I work for Tech-X Corporation and I am the product manager for GPULib.

GPULib 1.6 has greatly enhanced linear algebra capabilities: GPU accelerated LAPACK routines provided by MAGMA. See details on the GPULib blog. We provide a low-level interface to over 100 LAPACK routines.

MAGMA is a hybrid code that uses the CPU to do parts of the calculations that are best suited to it. We use Intel MKL to provide the CPU LAPACK.

MAGMA has been difficult to build, but I’m happy to say we have builds for OS X, Linux, and Windows!

Full disclosure: I work for Tech-X Corporation and I am the product manager for GPULib.

After a long wait, GPULib 1.6 is finally ready to download! Here’s the brief version of the release notes (for a more detailed list, see the GPULib blog):

• All platforms, Windows, Linux, and OS X, are now distributed as binaries. No building from source required!
• Added MAGMA (GPU accelerated LAPACK library) linear algebra routines.
• GPULib can now load and execute custom CUDA kernels without having to link to it; you just compile your kernel to a .ptx file. We provide routines to load and execute that kernel at runtime.
• Support for CUDA 5.0.
• Added support for up to 8-dimensional arrays.
• Added optimized scalar/array operations.
• Miscellaneous bug fixes.

A lot of work was done on infrastructure to make releasing an easier process, hopefully resulting in more frequent releases. We have plans for some very exciting features in the coming year!

Full disclosure: I work for Tech-X Corporation and I am the product manager for GPULib.

VISualize 2013, the annual IDL user group meeting, is planned for June 12-13 at the WWF headquarters in Washington, DC. Registration and call for abstracts are now open.

mgunit 1.3.0 has been released! mgunit makes unit testing your IDL code easy by removing most of the repetitive boilerplate code from your testing code. Here are the release notes for 1.3.0:

• Added optional OUTPUT keyword to tests which, if present and set during the the test, is echoed to the output.
• Added utilities to help test GUI applications.
• Updated “Using mgunit” documentation.
• Adding error_is_skip.pro batch file with optional variable MGUNIT_SKIP_MSG which can be set prior to including error_is_skip.pro to a message that will be used if an error causes the skip.
• Updated look for HTML output.

See the releases page on the Github repo to download.

IDL 8.2.2 was released today:

IDL 8.2.2 is now available for download from our website, exelisvis.com. Although it’s primarily a maintenance release (including 104 bugs fixed), it also has some meat, with updates in, primarily, the categories of (New) Graphics, language and file access.

Haven’t been able to download yet, but will take a look at this as soon as I can get my hands on it.

I’ve wanted IDL batch files to be executable scripts for awhile, but figured I would just have to live without that since IDL’s comment character is not #. But then found out that Scheme also uses the ; as the comment characters, but allows the first line to begin with #! (the shebang) and just ignores that line. So I made rIDL mimic that:

$ mg_shebang_test.pro
This is an executable rIDL script!

where the mg_shebang_test.pro script is:

#!/usr/bin/env ridl -quiet

; This is an example of an executable rIDL script that recognizes the shebang
; characters, #!, on the first line of the script.

print, 'This is an executable rIDL script!'

exit

This was actually quite simple to add to rIDL; I would love to see this feature in regular command line IDL.

To try to minimize administrative work for me (fighting spam, dealing with security, updating Trac, etc.) I’m moving all my libraries to GitHub: IDLdoc, mgunit, rIDL, and finally a complete personal library, mglib. These repos all have the same features that were available on my personal site: tickets (now called “issues”), wiki pages, and access code via version control (was Subversion, now is git). There are some nice, additional bells and whistles like the ability to download the current code as a zip file, social features, and lots more.

In particular, my personal library is now easily accessible and contains the old vis (now using the mg_ namespace instead of vis_), cmdline_tools, and dist_tools libraries as well as my other miscellaneous routines. I haven’t made formal releases of this library in the past, but I do use it for projects like IDLdoc and mgunit, which do have formal releases.

Here is the abstract for my poster at AGU this year, “GPU accelerated curve fitting with IDL”:

Curve fitting is a common mathematical calculation done in all scientific areas. The Interactive Data Language (IDL) is also widely used in this community for data analysis and visualization. We are creating a general-purpose, GPU accelerated curve fitting library for use from within IDL.

We have developed GPULib, a library of routines in IDL for accelerating common scientific operations including arithmetic, FFTs, interpolation, and others. These routines are accelerated using modern GPUs using NVIDIA’s CUDA architecture. We will add curve fitting routines to the GPULib library suite, making curve fitting much faster.

In addition, library routines required for efficient curve fitting will also be generally useful to other users of GPULib. In particular, a GPU accelerated LAPACK implementation such as MAGMA is required for the Levenberg- Marquardt curve fitting and is commonly used in many other scientific computations. Furthermore, the ability to evaluate custom expressions at runtime necessary for specifying a function model will be useful for users in all areas.

I will be giving the poster on Wednesday December 5, 2012 at 1:40 to 6 pm (will probably be there more towards the beginning of that time), IN33A-1532. Download.

I think the only surprising thing about this list of best practices is how many scientists are not doing them. The authors begin with the importance of software in science:

Software is as important to modern scientific research as telescopes and test tubes.

Then they move on to a list of best practices. I think most of the listed practices, e.g., use version control, DRY, test, etc., are common sense and should be known to scientists, even if not always practiced. But it is important to remember best practice #1:

Write programs for people, not computers

I would add one more practice:

• Wherever possible, use plain text.

It might be convenient to create a 24 pt bold Comic Sans title in a Word doc, but plain text (possibly in LaTeX, restructuredText, Markdown, or some other text formatting system) will work better with your version control system (best practice #5), automate nicely (best practice #2), and not lock you into a proprietary system (best practice #7).

I noticed the list of authors includes Greg Wilson from Software Carpentry, who I’ve mentioned before.

Link via Astronomy Computing Today.