1999/07/07
The latest version of this FAQ is always available from the IBM Research OpenDX web site, at <./faq.html>.
(Several of the answers to the questions found in this FAQ were adapted from the Apache FAQ.)
IBM 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. Thanks to community effort, the open source version is rapidly approaching the reliability of the product 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.
There is no official support for OpenDX. Bug reports and suggestions should be sent via the 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?
You can find out how to download the source for OpenDX at the project's web page.
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 collectionds of sample networks which demonstrate the use of most of the modules available for download.
Cornell has a collection of contributed modules, teaching materials, and other material at http://www.tc.cornell.edu/DX/ .
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.
The answer to this question can be found in the OpenDX license,
which is included in the OpenDX distribution in the file
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."
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.
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.
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".
The current version of OpenDX for sgi uses only 32bit addressing.
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 readv,
writev, or 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
opendx-dev@watson.ibm.com 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 -c' or 'diff -u' against
the most recent tarball. To submit your patch, send email to
gabra@us.ibm.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.
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.
Make sure that the ip address of localhost (127.0.0.1) is in /etc/hosts.
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.