Open Visualization Data Explorer (OpenDX) is an application and development software package for visualizing data, especially 3D data from simulations or acquired from observations. It uses a Graphical User Interface based on X windows and Motif. It comes with a complete set of standard visualization tools for looking at data. These tools include cutting planes, vector line traces, volume rendering, and isosurface/isocontour tools.
OpenDX is based on code and ideas found in the IBM Visualization Data Explorer program product. On May 18, 1999 IBM announced the withdrawal of the program product. A week later the creation of the IBM Open Visualization Data Explorer was announced in conjunction with the creation of the IBM Deep Computing Institute.
To foster the growth of the scientific visualization community.
The IBM Visualization Data Explorer program product was a well-tested, widely used tool. With the release of OpenDX 4.1.3, the open source version has reached the quality level of the release version. OpenDX also supports a larger number of platforms, including linux. When bugs do show up, we try to release patches and new versions as soon as they are available. We count on the participation of the OpenDX community to help find and solve problems.
The most recent release of OpenDX is version 4.3.2.
There is no official IBM support for OpenDX. Bug reports and suggestions should be sent via the bug report page. OpenDX hosts their own bug report page. Other questions should be directed to the appropriate OpenDX mailing list.
Commercial support for OpenDX is, however, available from third parties.
Yes, there is some legacy documentation available. Hopefully this documentation will be updated and converted to LaTex someday in the near future. Any volunteers?
The source code is available from IBM's DX pages as well as from OpenDX.org. Binary versions are available from OpenDX.org. Other commercial versions are distributed through vendors; look for more information at OpenDX.org.
The best way to understand how to use OpenDX is to purchase the book OpenDX: Paths to Visualization from VIS, Inc. The legacy documentation from the program product contains a step-by-step tutorial to take you through some of the common operations in OpenDX. Also, there is a collection of sample networks which demonstrate the use of most of the modules available for download.
The most comprehensive area for information on OpenDX is at OpenDX.org. Cornell University has a collection of contributed modules, teaching materials, and other materials which can be reached from the communities link at OpenDX.org.
OpenDX should be 100% compatitble with files and interfaces of the 3.1.4b version of IBM Visualization Data Explorer propram product.
Yes, we believe that OpenDX is Year 2000 compliant.
There are ports for almost all UNIX based operating systems as well as Microsoft Windows.
Yes. Starting with OpenDX 4.2, it is possible to compile OpenDX for MacOS X. If you'd like a binary version, visit VIS Inc.'s website for more inforamation.
Currently OpenDX will run on Microsoft Windows 98-XP but the graphical user interface requires an X server to be running. There have been some demonstrations of code ported to Window's native windowing system, but the amount of work required to port all of DX is large. There are people interested in porting this, but such a large project would require some financial backing. Please contact us at if you're interested in helping out with this or providing some financial backing.
The answer to this question can be found in the OpenDX
license, which is included in the OpenDX distribution in
LICENSE. You can also find it on the
Web at <http://www.research.ibm.com/dx/srcDownload/license.html>.
Good question. The answer is probably, "It depends." OpenDX is memory intensive, so the more memory the better. However, the way the software works limits the amount of physical memory that can be accessed by the program at 2 GB. (It currently does not support 64 bit data address spaces.)
No, since the OpenDX can render images in software, it does not require a hardware graphics card. However, if you have one, OpenDX can take advantage of it. The ability to do software rendering also means that you can run OpenDX and display the image on another workstation without having to have remote hardware rendering support.
It uses GL or OpenGL on IBM and SGI platforms, OpenGL on Suns, Starbase on the HPs, and OpenGL on DEC. The Data General version does not support hardware rendering. OpenDX uses OpenGL on PCs if available.
Yes, OpenDX exploits shared memory parallelism on SMP machines.
While OpenDX is a complete visualization environment, you can also build applications which use portions of OpenDX. For example you can use OpenDX behind the scenes to create your own special-purpose turnkey application with a custom look and feel. For an in-depth description of some of the many ways you can embed OpenDX functionality within your application see the legacy document entitled building applications.
Run "dx -version". It will print out three numbers, one for the User Interface, one for the Executive and one for the script which starts DX. Normally these numbers are all the same. You can also use the "Product Information" option of the Help menu of the Visual Program Editor.
It handles data on regular grids, warped grids, scattered points and unstructured data (triangular, quadralateral, tetrahedral or cubic meshes). It handles scalar, vector, matrix data; float, integer, short, byte, string data. It handles collections of data (groups, series, multizone grids).
This is an unfortunate artifact of caching. Since the input of import, the filename, does not change then the module does not run. Logic probably should be added to check on the timestamp of the file, but no one has yet addedd this feature.A simple hack is to force Import to reload a file by appending a "space" to the end of the file name. This can be repeated, that is, any new file string will force a new import. Alternatively, this can be done programatically by feeding the filename and a dummy integer into a Format module that simply does "%s" and ignores the incoming integer. By bumping the integer one can force a "new" filename that is identical to the previous and forces a reload when the dummy integer changes to a value not previously used. The simplest work-around is to use the "Reset Server" option under the Connection Menu. This throws away all the cached information which was saved from previous runs of OpenDX. You could also turn the cache off when OpenDX is started by using the "-cache off" option. These last two options can cause significant performance hits.
You can use the Print module. The default is to only print the type of object, but if you set the second parameter to "r", it will recursively print each member object. If the second parameter is "rd", it will also print the first and last 25 data items for each data array. You can also use the VisualObject module in the Debugging category. This will display a hierarchical image of the object. The Describe module (also in the Debugging category) will give you a "plain language" description of your object.
Use the Export module, connect the output you want to know about to the first input of Export. Set the second input to a temporary filename, and set the third input to "dx text follows". Then execute once and look at the ASCII file to see what the file format for that type of object would be.
For example if you want to specify a list of numbers between 0 and 10 by 2, just type: "0 .. 10 : 2". You can also use the Enumerate module to generate other types of number lists.
A list is the same as an "array".
Unless you are using the SuperviseWindow and SuperviseState modules, direct resizing of the window and direct interaction with the image must be performed with the Image tool, which acts something like a combination of AutoCamera and Display. If you are using Display, then to change the image size use the "resolution" and "aspect" parameters to Camera or AutoCamera, and to change viewing directions, change the "to" and "from", or "object" and "direction" parameters to Camera and AutoCamera. The SuperviseWindow and SuperviseState modules allow you to define your own "UserInteractors". For example, if you don't like how the rotate or pan modes works then this capability permits you to define your own version. Check the documentation for SuperviseWindow and SuperviseState and also check the supervise samples.
You can save an image using either the Image tool or Display. If you use the Image tool, you will find options for saving and printing images in the File menu of the Image window. If you use Display, you can use ReadImageWindow. First pass it the "where" output of Display and then pass the output of ReadImageWindow to WriteImage.
This problem is discussed in the documentation for AutoGlyph. There is a macro to do this, see samples/macros/UnsquishGlyph.net, which is used by samples/programs/ScatterData.net.
To specify multiple user-written modules on the command line when starting OpenDX, concatenate all of your individual .mdf files together into a single mdf file and use this file at startup. For example if the list of files is contained in a file named "allmodules.mdf" then then you would start OpenDX with the command "dx -mdf allmodules.mdf".
Some additional fonts can be downloaded from
Extracting this archive creates a
directory, including fonts in dx format and some sample output.
See the included
README file for more information.
There has been some work done with this. If you configure OpenDX with --enable-large-arenas turned on, and compile, you can get some support for 64 bit memory addressing. We are looking for financial support to make this more robust--if you have a funding source possibility, please contact us as email@example.com.
Out of all the X-servers on the market, Hummingbird's Exceed + Exceed 3D and Starnet's X-Win32 perform the best and offer OpenGL hardware rendering. The cheapast would have to be XFree86 based on cygwin.
If OpenDX source won't compile on your system, it is probably due to one of the following causes:
The OpenDX developers try to support as many platforms as possible. Unfortunately, they can't test all of the OS platforms there are. If you have verified that none of the above issues is the cause of your problem, please submit a problem report. Be sure to include complete details, such as the compiler & OS versions and exact error messages.
The gcc compiler parses your system header files and produces a modified subset which it uses for compiling. This behaviour ties gcc tightly to the version of your operating system. So, for example, if you were running IRIX 5.3 when you built gcc and then upgrade to IRIX 6.2 later, you will have to rebuild gcc. Similarly for Solaris 2.4, 2.5, or 2.5.1 when you upgrade to 2.6. Sometimes you can type "gcc -v" and it will tell you the version of the operating system it was built against.
If you fail to do this, then it is very likely that OpenDX will fail to build. One of the most common errors is with
uio.h. This is not a bug with OpenDX. You will need to re-install gcc.
If you are having trouble with OpenDX, you should take the following steps:
OpenDX tries to be helpful when it encounters a problem. In many cases, it will provide some details by writing one or messages. In particular pay attention to the first error message. It is almost always the most important one and usually explains subsequent error messages. To access these messages, use the "windows" pulldown and select "open message window". Sometimes this is enough for you to diagnose and fix the problem yourself (such as file permissions or the like).
The latest version of the OpenDX Frequently-Asked Questions list can always be found at the OpenDX web site.
Most of the OpenDX problems are recorded in the bug database. Please check the existing reports, open and closed, before adding one. If you find that your issue has already been reported, please don't add a "me, too" report. If the original report isn't closed yet, we suggest that you check it periodically. You might also consider contacting the original submitter, because there may be an email exchange going on about the issue that isn't getting recorded in the database.
A lot of common problems never make it to the bug database because there's an active discussion in one of the opendx mailing lists.
If you've gone through those steps above that are appropriate and have obtained no relief, then please let the OpenDX developers know about the problem by logging a bug report.
If your problem involves the OpenDX crashing and generating a core dump, please include a backtrace (if possible).
We encourage patches from developers. There are two main "types" of patches: small bugfixes and general improvements.
Bugfixes should be submitting using the OpenDX bug report page.
In general, the first course of action is to become a member
of the firstname.lastname@example.org mailing list. This indicates
to the group that you are closely following the latest OpenDX developments.
Your patch file should be generated using either '
diff -u' against the most recent tarball. To submit your
patch, send email to email@example.com with a Subject:
line that starts with [PATCH]
and includes a general description of the patch. In the body of the
message, the patch should be clearly described and then included at the
end of the message. If the patch-file is too long, you can provide a
URL for the file instead of the file itself.
Please be prepared to respond to any questions about your patches and possibly defend your code.
This problem can be caused if OpenDX wasn't installed using the standard install process. If you have to type a pathname in front of the "dx" command to start the User Interface, the User Interface will not be able to start the server part of DX. To fix this, add the "<PREFIX>/bin" directory to your search path.
The user interface and the server (exec) communicate over sockets. Netwoking must work in order for this process to work completely. There are several reasons why this communictaion may fail. One may be that your hostname does not resolve properly. You can test this by using the ping, and hostname commands to determine if you can ping your own machine or you can try setting the DXHOST environment variable to "unix" to default to the local machine. A second reason may be that you have a firewall running on your system that refuses the socket communication over the IP ports that DX uses. Try shutting off your firewall to see if this fixes the problem.
Sometimes, renaming /etc/resolv.conf will solve the problem. Don't forget to restore this file when you return to the network. Having entries in /etc/hosts for localhost and LOCALPC may be necessary to run OpenDX when not connected to a network. It may also be the case where your machine name can not be resolved. In these cases, try setting the environment variable DXHOST to localhost.
Make sure that the ip address of localhost (127.0.0.1) is in /etc/hosts on a UNIX system or in the HOSTS file on a Windows machine. On a Windows machine, the HOSTS file goes in the same directory as the LMHOSTS file, you can find the specific directory by searching for LMHOSTS.SAM (an example LMHOSTS file).
Check the README file for your specific architecture type. On some systems the default system limits must be changed to allow OpenDX to use more shared memory or a larger data segment. If all else fails, use the -memory flag on OpenDX to limit the amount of memory OpenDX uses.
You will need to use systune to increase the limit of shared memory. See README.sgi.
Backing storage may be unsupported or very slow on your hardware. To turn off backing storage you need to set the environment variable DX_NO_BACKING_STORE to a value of 1.
Ignore this warning, it apparently occurs only when you have modified the PPI setting of the Save Image or Print Image dialog. Note that it is NOT necessary to set the PPI to match the DPI of your printer. It is typically preferable to set the overall resolution of the image using the Input Image size field.
There are some known issues with sockets being too small and causing problems. This can be fixed by setting the DX_SOCKET_BUFSIZE environment variable to a number larger than the typical default of 32K. One suggested size is 262144 but different OSs may be limited.
Some operating systems have a set limit for socket buffer sizes so they must be increased as well. For example, Redhat Linux sets this limit in the following two files: /proc/sys/net/core/rmem_max, /proc/sys/net/core/wmem_max. They can be increased by changing the values within these files. For example:
echo 262144 > /proc/sys/net/core/rmem_max
echo 262144 > /proc/sys/net/core/wmem_max
There are multiple ways to reduce memory requirements of a network. The quickest ways are: