There are a number of different options for incorporating compiled code such as C and Fortran into IDL. This document outlines the possible approaches and contains some discussion on which methods are appropriate for a given situation. This document is essentially an overview of the IDL EXTERNAL DEVELOPMENT GUIDE (previously the Advanced Development Guide).
If at all possible and rewriting time and speed are not of paramount importence you should rewrite any legacy routines in IDL. However, it is often necessary, in situations where existing code is too long to be practically rewritten or a clear speed advantage exists, to call external code from within IDL.
It should be noted that while in some situations IDL can be slower than the C or Fortran equivalent, this is not always the case; particularly when use of IDL's vectorized code features can be made.
OK you've decided that rewriting is not an option, the decision of how to incorporate your code into IDL needs to be made. The method used depends on a number of considerations: does your solution need to work on a number of different systems (Unix, windows, mac, VMS) or just the one; what level of complexity are you capable of (most of the possible incorporation methods require a large amount of knowledge about system specific features, IDL internals, or both); will your application benefit significantly from system specific features such as RPC under Unix; and how deeply linked into IDL does your external routine really need to be?
Outlined below are the possible options for combining Fortran and C with IDL. With the considerations above these outlines should help you decide which option is appropriate for you. In most situations the answer will be CALL_EXTERNAL. There are three main reason for this: (i) CALL_EXTERNAL is supported on all systems that IDL runs on; (ii) the simplest possible method (SPAWN) is also exceptionally limited, especially on non-Unix systems; and (iii) the system specific (RPC etc.) and most deeply linked (LINKIMAGE and DLMs) methods require more background knowledge than most people have or have the time to acquire.
SPAWN simply gives access to the command line so you can run a command. It creates a process with its own process space.
If the external code you want incorporated is standalone then SPAWN is the simplest way of accessing that routine from IDL.
SPAWN is too limited in most situations of incorporating external code. However, it is worth keeping in mind as a way of accessing system commands; particularly on Unix.
Allows called process to be run on another machine, possibility of overlapped execution on a networked or multi-processor system.
Unless there is a significant advantage in parallel or remote processing this approach is probably a bit extreme.
The above are all ways of calling external code from IDL. It is also possible to call IDL from within other programs, e.g. C or Fortran.
The IDL directory on your computer contains examples and files containing information that may be of use.
CALL_EXTERNAL is invoked as a function call from within IDL, typically called from within a user written procedure or function (ie not directly from the command line.
Result: is a variable into which the function returns a value. If you're calling a function this will be the value of interest, however, if you're calling a subroutine the value/s of interest are more likely passed through the routines interface and Result can be used to determine the status of the call e.g. failed/succeeded
Image: is a string containing the name of the compiled and linked sharable object. (*.so on UNIX; *.dll on Windows)
Entry: The name of the point of entry into the routine, ie the routine name inside the shared object; this varies from compiler to compiler. Under UNIX type nm *.so at the command line to a name listing of your object and thus determine how the entry point was renamed by the compiler; typically this involves appending or prepending an underscore to your particular routine name.
[P , ...,P ]: refers to the arguments passed to your external routine. The default is to pass by reference. These arguments can be scalars, arrays, and strings.
CALL_EXTERNAL performs no checking of the number and type of parameters. It is therefore best to include error checking in your IDL code. This can be done by putting CALL_EXTERNAL in an IDL function which takes care of any required checking, this has the added advantage of providing a neat interface to your external routine.
While strings can be passed it is best to avoid this if possible. Strings are passed as structures which results in an additional level of complexity in the wrapper-routine interface. As such slight system/compiler/language inconsistencies can cause additional headaches.
(1) If your external routine was written to be reusable (ie not written for use in one specific piece of code) then you should be able to start at step (2). However, if this is not the case...
(2) Write a wrapper function. This is a function that facilitates communication between IDL and your external routine by acting as an interface between them. This can be written in Fortran or C.
Now you external function can be called and used as though you had rewritten the entire thing as an IDL function.
Look at the example code in this directory. Try compiling and linking the example on your system (see Shared_obj_comp.txt)
The example consists of: a piece of Fortran code, vecadd.f, which is the external routine being called from IDL; a Fortran wrapper for vecadd.f called vecadd_wrapf.f; a C wrapper for vecadd.f called vecadd_wrapc.c; and an IDL function called vecadd.pro which provides a neat interface from within IDL to the CALL_EXTERNAL function.
NSPA does not perform a quality audit prior to posting any courses. Inclusion of a course on this page does not constitute an NSPA endorsement of the course. Members should carefully review the trainer's credentials as well as the course's evidence base and relevance before signing up.
As an aid to critical evaluation of courses teaching new and emerging practices, the Nova Scotia College of Physiotherapists provides a useful tool: Is It Physiotherapy? Tool to Consider Emerging Practices.
If you intend to register for any of the courses listed, please do so ASAP. There is the possibility that courses will need to be cancelled or rescheduled if there are not enough participants registered ahead of time.