Re: [opendx-dev] compile on 2cpu amd_64; rhel3
Here's a further update, for everyone's reference. The 64-bit version of the nvidia driver is definitely broken. But there are some workarounds for now. As a test, I installed the 32-bit version of RHEL-WS3.0 with the latest version of the standard x86 version of the nvidia driver. The RH9 4.3.2 rpm on the web site installed right away and everything works. Compared to the version I built from the July 30 4.3.3 tarball for the 64-bit version of RHEL, various modules run anywhere from 10% to 50% slower with the 32-bit RHEL. Nevertheless, the machine is still pretty fast. For anyone else that ends of doing this as a workaround, there is a known 32-bit RedHat issue on some Opteron machines if they have more than 4GB of RAM because the area of memory reserved for caching the AGP aperture ends up above that space, so AGPGART ends up with no memory and video performance disappears. The workaround is restricting the memory with 'mem=4095M' as a kernel option in the grub menu. Obviously, any additional memory is wasted, but the 32-bit kernel wouldn't be addressing it anyway... |-+-- | | Lloyd A| | | Treinish/Watson/[EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | son.ibm.com| | | | | | | | | 10/19/2004 02:26 PM| | | Please respond to | | | opendx-dev | | | | |-+-- | | | | To: opendx2-dev@lists.berlios.de | | cc: | | Subject: Re: [opendx-dev] compile on 2cpu amd_64; rhel3 | | | | Here's an update, for everyone's reference. I have been able to successfully make a few different builds with the July 30 4.3.3 tarball for the Opteron RHEL-WS3.0 system. The first was with large-arena and SMP support: ./configure --with-netcdf --with-large-arenas --enable-dependency-tracking --enable-smp-linux --includedir=/usr/include:/usr/local/include --libdir=/usr/lib64:/usr/local/lib --x-libraries=/usr/X11R6/lib64 --x-includes=/usr/X11R6/include The second was with small arenas and no SMP support. In both cases, I built a version of the libnetcdf for this platform. ./configure --with-netcdf --enable-dependency-tracking --includedir=/usr/include:/usr/local/include --libdir=/usr/lib64:/usr/local/lib --x-libraries=/usr/X11R6/lib64 --x-includes=/usr/X11R6/include Unfortunately, dxexec from the SMP build hangs when two cpus are requested. With p1, it works fine. In addition, requests for memory beyond 2GB remained clipped at 2 GB. Both versions appear to perform similarly when running with a single cpu and less than 2GB of memory (pretty fast). The hardware rendering problem is the same in both versions, which suggests problems from nvidia. I tried building with and without pointing specifically to the gl includes from nvidia, although it didn't seem to matter. I have also sent an e-mail to nvidia's support group, but I have not received a response yet. Lloyd A Treinish/Watson/[EMAIL PROTECTED] To: Sent by:opendx2-dev@lists.berlios.de [EMAIL PROTECTED] cc: ibm.com Subject:Re: [opendx-dev] compile on 2cpu amd_64; rhel3 10/17/2004 07:07 PM Please respond to opendx-dev I figured that was the situation. I have not had the chance to look into it in much more detail. I just booted the machine for the first time on Friday and tried the few things that I cited in my posting. Unfortunately, I don't have the time to put
Re: [opendx-dev] compile on 2cpu amd_64; rhel3
Here's an update, for everyone's reference. I have been able to successfully make a few different builds with the July 30 4.3.3 tarball for the Opteron RHEL-WS3.0 system. The first was with large-arena and SMP support: ./configure --with-netcdf --with-large-arenas --enable-dependency-tracking --enable-smp-linux --includedir=/usr/include:/usr/local/include --libdir=/usr/lib64:/usr/local/lib --x-libraries=/usr/X11R6/lib64 --x-includes=/usr/X11R6/include The second was with small arenas and no SMP support. In both cases, I built a version of the libnetcdf for this platform. ./configure --with-netcdf --enable-dependency-tracking --includedir=/usr/include:/usr/local/include --libdir=/usr/lib64:/usr/local/lib --x-libraries=/usr/X11R6/lib64 --x-includes=/usr/X11R6/include Unfortunately, dxexec from the SMP build hangs when two cpus are requested. With p1, it works fine. In addition, requests for memory beyond 2GB remained clipped at 2 GB. Both versions appear to perform similarly when running with a single cpu and less than 2GB of memory (pretty fast). The hardware rendering problem is the same in both versions, which suggests problems from nvidia. I tried building with and without pointing specifically to the gl includes from nvidia, although it didn't seem to matter. I have also sent an e-mail to nvidia's support group, but I have not received a response yet. Lloyd A Treinish/Watson/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/17/2004 07:07 PM Please respond to opendx-dev To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] compile on 2cpu amd_64; rhel3 I figured that was the situation. I have not had the chance to look into it in much more detail. I just booted the machine for the first time on Friday and tried the few things that I cited in my posting. Unfortunately, I don't have the time to put a lot of effort into this. So, I'll do some more experimentation and report any useful findings. However, I see the most serious problem as being with the OpenGL drivers, for which I don't expect an immediate solution. Admittedly, I don't have a lot of experience on 64-bit platforms. I have found that under AIX I didn't have a lot of these problems. On the other hand, I only use those systems for production visualization with software rendering. |-+-- | | David Thompson | | | [EMAIL PROTECTED]| | | Sent by: | | | [EMAIL PROTECTED]| | | son.ibm.com | | | | | | | | | 10/17/2004 05:40 PM| | | Please respond to | | | opendx-dev | | | | |-+-- ---| | | |To:opendx2-dev@lists.berlios.de | |cc: | |Subject: Re: [opendx-dev] compile on 2cpu amd_64; rhel3 | | | ---| With linux and shared libraries, you need to use ldconfig to help the os find them. As for the library incompatibility, this is going to be a 64 bit OS library versus a 32 bit OS library. The libtool guys have been discussing how to handle some of this--but they still have not come to any kind of consensus. As of now, no one has come forward to start working on any of the 64 bit os issues beyond the SGI. So unless someone is willing to undertake this or pay someone (like myself) to undertake it--I wish you luck. David Coincidently, I just got a similar box as a loaner for a couple of weeks and I am seeing similar problems. It's a dual 2.2GHz AMD Opteron system running RHEL-WS3.0 for x86_64 with an SMP kernel (2.4.21-20.ELsmp). It has gcc v3.2.3 (from Red Hat Linux 3.2.3-42). The system has an nVidia Quadro FX3000 with the latest driver from nvidia.com for this architecture. I started by using the latest tarball (July 30, 2004) for OpenDX 4.3.3. My initial attempt was to make a build for large arena and SMP enabled as well as with netCDF. I had to build a netCDF library for this platform, but it seems to work ok. Anyway, the dx build creates an executable but reports similar loader problems: /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXpm.so when searching for -lXpm /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXpm.a when searching for -lXpm /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXp.so when searching for -lXp /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXp.a when searching for -lXp /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXmu.so when searching
Re: [opendx-dev] compile on 2cpu amd_64; rhel3
I figured that was the situation. I have not had the chance to look into it in much more detail. I just booted the machine for the first time on Friday and tried the few things that I cited in my posting. Unfortunately, I don't have the time to put a lot of effort into this. So, I'll do some more experimentation and report any useful findings. However, I see the most serious problem as being with the OpenGL drivers, for which I don't expect an immediate solution. Admittedly, I don't have a lot of experience on 64-bit platforms. I have found that under AIX I didn't have a lot of these problems. On the other hand, I only use those systems for production visualization with software rendering. |-+-- | | David Thompson | | | [EMAIL PROTECTED]| | | Sent by: | | | [EMAIL PROTECTED]| | | son.ibm.com| | | | | | | | | 10/17/2004 05:40 PM| | | Please respond to | | | opendx-dev | | | | |-+-- ---| | | | To: opendx2-dev@lists.berlios.de | | cc: | | Subject: Re: [opendx-dev] compile on 2cpu amd_64; rhel3 | | | ---| With linux and shared libraries, you need to use ldconfig to help the os find them. As for the library incompatibility, this is going to be a 64 bit OS library versus a 32 bit OS library. The libtool guys have been discussing how to handle some of this--but they still have not come to any kind of consensus. As of now, no one has come forward to start working on any of the 64 bit os issues beyond the SGI. So unless someone is willing to undertake this or pay someone (like myself) to undertake it--I wish you luck. David Coincidently, I just got a similar box as a loaner for a couple of weeks and I am seeing similar problems. It's a dual 2.2GHz AMD Opteron system running RHEL-WS3.0 for x86_64 with an SMP kernel (2.4.21-20.ELsmp). It has gcc v3.2.3 (from Red Hat Linux 3.2.3-42). The system has an nVidia Quadro FX3000 with the latest driver from nvidia.com for this architecture. I started by using the latest tarball (July 30, 2004) for OpenDX 4.3.3. My initial attempt was to make a build for large arena and SMP enabled as well as with netCDF. I had to build a netCDF library for this platform, but it seems to work ok. Anyway, the dx build creates an executable but reports similar loader problems: /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXpm.so when searching for -lXpm /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXpm.a when searching for -lXpm /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXp.so when searching for -lXp /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXp.a when searching for -lXp /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXmu.so when searching for -lXmu /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXmu.a when searching for -lXmu /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when searching for -lXext /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXt.so when searching for -lXt /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXt.a when searching for -lXt /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libSM.so when searching for -lSM /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libSM.a when searching for -lSM /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libICE.so when searching for -lICE /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libICE.a when searching for -lICE I've noticed that this occurs whether it's pointing to /usr/X11R6/lib or /usr/X11R6/lib64. I was going to experiment with other building options (with and
Re: [opendx-dev] compile on 2cpu amd_64; rhel3
Coincidently, I just got a similar box as a loaner for a couple of weeks and I am seeing similar problems. It's a dual 2.2GHz AMD Opteron system running RHEL-WS3.0 for x86_64 with an SMP kernel (2.4.21-20.ELsmp). It has gcc v3.2.3 (from Red Hat Linux 3.2.3-42). The system has an nVidia Quadro FX3000 with the latest driver from nvidia.com for this architecture. I started by using the latest tarball (July 30, 2004) for OpenDX 4.3.3. My initial attempt was to make a build for large arena and SMP enabled as well as with netCDF. I had to build a netCDF library for this platform, but it seems to work ok. Anyway, the dx build creates an executable but reports similar loader problems: /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXpm.so when searching for -lXpm /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXpm.a when searching for -lXpm /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXp.so when searching for -lXp /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXp.a when searching for -lXp /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXmu.so when searching for -lXmu /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXmu.a when searching for -lXmu /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when searching for -lXext /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXt.so when searching for -lXt /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXt.a when searching for -lXt /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libSM.so when searching for -lSM /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libSM.a when searching for -lSM /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libICE.so when searching for -lICE /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libICE.a when searching for -lICE I've noticed that this occurs whether it's pointing to /usr/X11R6/lib or /usr/X11R6/lib64. I was going to experiment with other building options (with and without large arenas, with and without SMP support), although I'll doubt it will matter since it seems to be just a ui problem. I have also seen problems with hardware rendering. A few from the sample set seem to work fine (i.e, changing rendering to hardware mode first or others like TextureMap). When I run something more complex, some screen objects are visible (e.g., Captions) while others are not (e.g., labels on color bars). When I rotate a 3d object, the surfaces will disappear as if an opaque triangle colored with the background color is draw in front, which grows with further rotation. The problem is repeatable. Software rendering seems ok, but I've not done exhaustive testing. My initial guess as to the rendering (not the loader) problem is with the driver from nVidia (see http://www.nvnews.net/vbulletin/showthread.php?s=1a67d4b4573fcbe9d9001c1ef411a486t=34005, for example). As an alternative, I also tried to install the RH9 4.3.3 rpm, which works just fine on RHEL-WS3 Intel boxes. At installation it complains about libxml and libpng being missing, although are there, and LD_LIBRARY_PATH and LIBPATH point to the right place. I can use --force and --nodeps to get beyond that. None of the executables will run, complaining about not being able to fine libpng even with the environment variables set correctly. I am also open to any suggestions on either of these issues as I continue to look into them. Thanks. |-+-- | | Peter Connolly | | | [EMAIL PROTECTED]| | | lsruhe.de | | | Sent by: | | | [EMAIL PROTECTED]| | | son.ibm.com| | | | | | | | | 10/13/2004 04:27 PM| | | Please respond to | | | opendx-dev | | | | |-+-- ---| | | | To: opendx2-dev@lists.berlios.de | | cc: | | Subject: [opendx-dev] compile on 2cpu amd_64; rhel3 | |
Re: [opendx-dev] AIX 5.2 Power4 binaries
Thanks. I would have been surprised if you told me that you still had access to an AIX system, but I thought I would ask before doing a build myself. I realize the most people think about only using DX interactively, and I do using Intel/Linux machines with nVidia cards. But I also do automated/batch production visualization to populate web sites from numerical model results using the same parallel AIX machine that runs the model. A bunch of SMP Power4 or Power3 nodes on IBM's fast switch can generate a lot of images quickly from GBs of data produced on that same machine... David Thompson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/12/2004 01:46 PM Please respond to opendx-dev To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] AIX 5.2 Power4 binaries Lloyd, I think I was the only one doing any AIX builds, and now that UCLA no longer has their AIX systems--nobody has requested that I do it (plus I no longer have availability to a system). I would recommend getting the latest CVS. There are a few very good bug fixes in it and very little new stuff has been added since 4.3.2. David I was wondering if anybody has built a binary for AIX 5.2 for Power4 or even generic Power systems? Earlier versions of DX that I have (4.0.9, 4.1.1 and 4.2.0) built generically for AIX 4.3.* run on AIX 4.3.3 and AIX 5.1 with either Power3 or PowerPC processors as well as AIX 5.2 with Power4 processors. I thought I would ask before doing a custom build for OpenDX 4.3.2, unless someone recommends using a newer tarball. Thanks. -- . David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804 Phone : (406)756-7472
[opendx-dev] AIX 5.2 Power4 binaries
I was wondering if anybody has built a binary for AIX 5.2 for Power4 or even generic Power systems? Earlier versions of DX that I have (4.0.9, 4.1.1 and 4.2.0) built generically for AIX 4.3.* run on AIX 4.3.3 and AIX 5.1 with either Power3 or PowerPC processors as well as AIX 5.2 with Power4 processors. I thought I would ask before doing a custom build for OpenDX 4.3.2, unless someone recommends using a newer tarball. Thanks.
Re: [opendx-dev] Interpolation functions in Map and Regrid
I saw where Greg posted some answers to your questions. In addition, Regrid uses a variation of Shepard's Method, but enabling more flexibility in the order of interpolant among other things. I have an old paper that describes some of the implications of these choices at http://www.research.ibm.com/dx/proceedings/peru/index.htm, for your reference. Kenneth L Gage [EMAIL PROTECTED]@opendx.watson.ibm.com on 06/15/2003 09:59:50 AM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] Interpolation functions in Map and Regrid Dear DXers - I've been working on interpolating data from an irregular connected tet grid to a regular hex grid using Map and Regrid. The Regrid module mentions that the interpolation function is 1/r^(exponent), and it appears that Map performs some form of spatial weighting for points within the tet mesh. Does someone know the official names of the interpolation algorithms implemented for these two modules? I would like to look them up somewhere to get a better feel for what is actually being performed in the modules. Please forgive me if the answer has been discussed before - I couldn't find specifics on the mailing lists, and I've been paging through the source for hours (my C ain't what it used to be). Thanks in advance! Ken ++ Kenneth Gage MD/PhD Student McGowan Institute for Regenerative Medicine University of Pittsburgh Department of Chemical Engineering
Re: [opendx-dev] Can opendx be wrapped in python?
Randall Hopper did some work with DX and Python some time ago. See http://people.freebsd.org/~rhh/py-opendx/ Chen Fu [EMAIL PROTECTED]@opendx.watson.ibm.com on 05/02/2003 04:43:33 AM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] Can opendx be wrapped in python? Hi! I take quite a long time to make opendx play on my win2k platform, and feel not comfortable with Xwindows features. I just wonder whether it is possible to wrap the core of opendx into python lib and then write some GUI in python to make it run on every platform? Can opendx's core function be sperate from Xwindows? = Remote Scensing Satellite Ground Station Chinese Academy of Science _ Do You Yahoo!? 相见不如聊天!不出门一样面对面！网络摄像头对对派送中~赶快用你的雅虎电邮帐号 参与吧…… http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.messenger.yahoo.com/
Re: [opendx-dev] unexplaned failure to connect under RH8.0
I have run DX 4.2 on a number of RH8.0 systems -- not the binary download, but built from the 4.2 tarball. I haven't seen that behavior. Could you be more specific as to the problem, environment, version? Richard Gillilan [EMAIL PROTECTED]@opendx.watson.ibm.com on 03/13/2003 02:10:20 PM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] unexplaned failure to connect under RH8.0 For no obvious reason, my OpenDX under Red Hat 8.0 just quit working: failure to connect to server. Nothing I know of has changed on the system. This actually happened once before and the started working again some days later. (I've tried setting DXHOST to all kinds of things with no luck). Anyone seen this type of thing before? Richard Gillilan MacCHESS, Cornell
Re: [opendx-dev] Re: [opendx-users] What tool or software can help me to generate moviefile from OpenDX animation?
Well, those ideas had been discussed long ago. As with image manipulation, the question of where do you draw the line for open-ended requirements, avoiding reinventing the wheel, and platform dependency must be considered. It seems to me to be easiest to do this external to DX given these issues. That's why there is some discussion of how-tos in the documentation and in the bonuspak (from 1996). Because some approaches (e.g., MPEG) require manipulation of multiple frames simultaneously and some computational cost, that certainly suggests a post-processing approach external to DX. I have preferred doing this way because it gives more control to produce the type of animations I require. Rob Lahaye [EMAIL PROTECTED]@opendx.watson.ibm.com on 02/24/2003 01:25:29 AM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-users@lists.berlios.de, opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] Re: [opendx-users] What tool or software can help me to generate moviefile from OpenDX animation? Hi, I wonder whether it's along the lines of OpenDX philosophy to put a Movie-tool on the wish-list or to-do-list ? This tool should handle all the cumbersome possibilities suggested by the replies to my earlier question on how to generate a movie file. Likewise the Image-tool that can output in a number of image formats, it would be great if the Movie-tool could output in a number of movie formats. Just an idea. Rob.
Re: [opendx-dev] changes to the vpe
Martin, looks nice. It certainly will be handy for some things that I do. I never use drag-and-drop nor ALL, so that doesn't bother me. Of course, my VPE habits started well before they were available, and thus, are hard to break. ALL was added when customers complained that they didn't understand the categories and therefore, didn't know where to look for modules. Of course, they never bothered reading the manuals or understanding some of the rationale. I don't know if that's still a concern among current users or not. Thanks. Martin S. Tignor [EMAIL PROTECTED]@opendx.watson.ibm.com on 02/13/2003 02:58:53 PM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] changes to the vpe Hello, I plan to check in code in the src/uipp directory that will change the tool selector in the vpe. There are a lot of files involved. This will happen in the next day or 2 or 3, I think. After you see all the check-in messages, just be aware things might be a little unstable for a day or 2. ...in case I have to fix bugs or cross-platform problems or whatever. What changes: - The tool selector becomes a set of tabbed pages that resemble the canvas area in appearance. There are 2 pages. One page is a new tool selector that is pretty much like the old one. The 2nd page is a list of recently used files. Double click in the list to open a file. Dxui saves the list when it exits and reloads it at start up. - The 2-list implementation of the tool selector is replaced with an outliner. - Type-ahead in the tool selector has an associated text widget that appears/disappears as needed. - If ( ALL ) is open when you use type-ahead, then type-ahead will locate a tool in ( ALL ). Otherwise the tool is located in its category. - Drag-n-drop to/from the tool selector is gone but I think it was never really needed, anyway. I'll be interested in reactions. One that I've gotten so far is that it might be better to remove the ( ALL ) category from the categorized list and put it in a separate page. Martin
Re: [opendx-dev] compiling DX under RedHat 8.0
I have RH8 on a new system with automake 1.63 and autoconf 2.53. I did a build recently without any problem using the 4.2 tar ball. The only change I made was to dx/include/dxconfig.h per the recent discussion about the variable HAVE_STRSTREAM_H Martin S. Tignor [EMAIL PROTECTED]@opendx.watson.ibm.com on 02/07/2003 03:43:10 PM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:Re: [opendx-dev] compiling DX under RedHat 8.0 On Fri, 2003-02-07 at 13:51, Ned Piburn wrote: Where are we with regard to compiling DX under RedHat 8.0? The only thing I use is redhat 8. The automake and autoconf I use are not the ones that came with the system. $ automake --version automake (GNU automake) 1.3 $ autoconf --version Autoconf version 2.13 Martin Ned Piburn [EMAIL PROTECTED]@opendx.watson.ibm.com on 02/07/2003 01:51:30 PM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] compiling DX under RedHat 8.0 Where are we with regard to compiling DX under RedHat 8.0? I've been using DX with RH 7.3 with no problem, but 8.0 is being just plain ugly. Below are my two attempts to set the DX construction machinery in motion. I'm about ready to cut my losses and load 7.3. Can someone suggest something I'm missing? Thanks, Ned Piburn First I tried configuring from the dx-4_2_0_tar tarball. As you can see below, that failed in the navel examination phase. checking for time.h... no checking for types.h... no checking for unistd.h... no checking for values.h... no checking for wait.h... no O_RDONLY IS NOT defined by default checking for windows.h... (cached) no checking for unistd.h... (cached) no checking for sys/types.h... (cached) no checking for sys/stat.h... (cached) no could not find working combination of stat function and structure falstaff5 Next I tried the CVS approach. The configure script hardly got started when it fell on its bum. falstaff70 CVSMake WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `include/dxconfig.h.in' is unchanged falstaff71 configure configure: line 10: syntax error near unexpected token `;;' configure: line 10: `' ECHO_T=' ' ;;' falstaff72
Re: [opendx-dev] QUADRO4 900 XGL graphics card versus GEFORCE4 Ti 4600
An interesting question. The problem, without trying both directly on the same machine, is that nVidia pushes the quadro for workstation applications and you can see Viewperf benchmarks while the GeForce is for gamers, for which you won't typically find Viewperf results posted. They do share some of the underlying components. Of course, there is over a 4x difference in street prices. System vendors will configure machines with the Quadro for professional workstations while they will use the other for home PCs. The best you probably can do for standard benchmarks is look for tests using Quake or some other OpenGL-based game. I had crudely compared previous generation cards on older machines (GeForce4 MX and Quadro2). The quadro2 was a bit faster, but a lot more money. Take a look at http://www17.tomshardware.com/graphic/02q2/020418/index.html vs. http://www.spec.org/gpc/opc.data/vp7/dx-perf.html But I did find the following, which suggests there is a significant difference, but not one that justifies the price difference... http://www.digit-life.com/articles2/profcards/profcards-09-2002-svp.html Marilyn E Noz [EMAIL PROTECTED]@opendx.watson.ibm.com on 11/07/2002 10:30:15 AM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] QUADRO4 900 XGL graphics card versus GEFORCE4 Ti 4600 Does anyone know which of these NVIDIA graphics cards performs better with DX - particularly for large volume arrays and heavy processing. Thank you. Marilyn
Re: [opendx-dev] Newbie Help : Cone Glyphs
I don't know what type of geometry that macro generates. But you can decompose some objects (e.g., made of quads) into triangles with Refine. Try something like: cone_macro | Refine(,triangles) | | ---Glyph | Wyn Williams [EMAIL PROTECTED]@opendx.watson.ibm.com on 08/06/2002 04:16:19 AM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] Newbie Help : Cone Glyphs Hi, I am trying without much success to have a cone type glyph at each point of a 3D vector field. I know that I can generate a cone-like shape using the macro at Cornell repository, however I cant put this into the Glyph module since it only accepts lines or triangles. Am I missing something obvious here ? Thanks Wyn Williams
Re: [opendx-dev] Page picklist shrinks to zero width
I've seen it in every version on Linux I used, which has been since summer of 2000. It was annoying, but didn't bother me. When I click on the select list the full list pops up. David Thompson [EMAIL PROTECTED]@opendx.watson.ibm.com on 02/22/2002 05:57:43 PM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:Re: [opendx-dev] Page picklist shrinks to zero width Am I right in assuming this is a new problem with CVS and not an old problem in 4.1.3? Lloyd's observation is what made me wonder. David I'm working on a network with 18 pages in dxui. Everytime I select the page select tab ... to switch pages, the width of the select list has shrunk. After 7 picks, there's only the vertical scrollbar. After 8, the whole list is only one pixel wide. Anyone know of a fix or resource hack for this? Thanks, Randy -- Randall Hopper (mailto:[EMAIL PROTECTED]) Lockheed Martin Operation Support EPA Scientific Visualization Center US EPA N127-01; RTP, NC 27711 -- . David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
[opendx-dev] MKS and DX
Anybody have any experience with OpenDX and the X server with OpenGL support from MKS (MKS Toolkit for Interoperability)? Just curious... Thanks.
Re: [opendx-dev] MKS and DX
I forgot to mention that the MKS Xserver is the Tarantella (formerly SCO) XVision X Server (http://www.mkssoftware.com/products/tk/ds_scox.asp). Lloyd A Treinish/Watson/[EMAIL PROTECTED]@opendx.watson.ibm.com on 02/16/2002 10:55:57 AM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] MKS and DX Anybody have any experience with OpenDX and the X server with OpenGL support from MKS (MKS Toolkit for Interoperability)? Just curious... Thanks.
[opendx-dev] OpenGL rendering of lines
I noticed an obscure feature the other day. In h/w rendering, if you request multi-pixel lines and opacity is not 1, then the lines are always rendered with single pixel width. If anyone is looking at the relevant code, it would occasionally be useful to do translucent, multi-pixel lines.
Re: [opendx-dev] GL_LIGHT_MODEL_TWO_SIDE
The consistency issue has come up long ago... When I have run into this situation, flipping the normals (i.e., Mark (,normals)-Compute(-a)-Unmark), has solved it and I still keep single-sided lighting. I don't know if that will apply for you. S/W rendering supports front and back colors, for example, and other features not in h/w rendering... Randall Hopper [EMAIL PROTECTED]@opendx.watson.ibm.com on 12/13/2001 04:33:29 PM Please respond to opendx2-dev@lists.berlios.de Sent by:[EMAIL PROTECTED] To:opendx2-dev@lists.berlios.de cc: Subject:[opendx-dev] GL_LIGHT_MODEL_TWO_SIDE Can anyone think of a good reason why the GL_LIGHT_MODEL_TWO_SIDE mode shouldn't be turned on for H/W rendering? Where it matters: datasets w/o normals and no particular ordering of the vertices (e.g. large external datasets that aren't practical to fix). The wrong normal is computed, which fouls up the lighting equation and generated colors. These datasets light and render cleanly with S/W rendering, so I presume S/W rendering is implicitly doing two-sided lighting. For consistency sake, seems like H/W rendering should too. Any objections to uncommenting this mode in hwPortOGL.c? Thanks, Randy __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com
Re: [opendx-dev] Re: Big net slowing down (in UI)
Per my comment yesterday, I have found the overall design for networks of similar size to strongly influence these performance issues. It doesn't make the problem go away, but helps work around it. Also, the basic speed of the UI on a particular machine is driven primarly by the clock speed of a single cpu given no architecture-specific optimization in the code. So that dual 300 MHz SGI is a slug compared to a cheap PC with a GHz processor, lots of RAM and a decent gaming card. Randall Hopper [EMAIL PROTECTED]@opendx.watson.ibm.com on 08/28/2001 08:04:37 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: [opendx-dev] Re: Big net slowing down (in UI) Chris Pelkie: |Hi Mark. I remember that monster. | |In my case, it's not the exec performance (that's not noticeably bad) |but the UI. I don't remember the earlier genetic parent of this net |slowing down though it was probably about as big. That's why I |wondered if people had seen this slowing response time in the UI |itself. It's too damn big to rebuild from the ground up, starting |from scratch to reset the module numbering back to 1. Hi Chris. Mark and I have definitely seen this, and it's still an issue with DX 4.1.3. The net from hell takes around 35 sec to load (second time, -uionly mode, net/macros/dx all in disk cache, local IPC X display), from OK-click to when you see the network and get UI control back. Switching pages may take up to 7 seconds, and creating control panels may take 5. BTW this is on a dual 300MHz R12k w/ 1GB mem. Randy -- Randall Hopper (mailto:[EMAIL PROTECTED]) Lockheed Martin Operation Support EPA Scientific Visualization Center US EPA MD/24 ERC-1A; RTP, NC 27711
Re: [opendx-dev] ui core dumps when reading a big net
I was able to solve the problem. I referenced an old version of a macro that had a different number of inputs and outputs that the newer one, which was used by the updated network. The extra tabs were hidden (ctrl-h), so I missed it when I looked at the network in the VPE. The difference is clear in the .net file. Anyway using the right version of the macro made the problem go away. So, this might be an obscure tip for anyone that runs into this problem... Lloyd A Treinish/Watson/[EMAIL PROTECTED]@opendx.watson.ibm.com on 08/24/2001 03:22:00 PM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de, opendx2-users@lists.berlios.de cc: Subject: [opendx-dev] ui core dumps when reading a big net I have some complex nets that I recently updated on a Linux system (OpenDX 4.1.0) and then moved to both AIX (4.0.9), other Linux (4.1.3) and Windows (4.1.1 and 4.1.3) systems. I have done this before without problem. However, one of the nets no longer works on Windows. The other nets work fine, and all of them work on the other platforms. The UI core dumps when reading in the net reporting internal error detected at node.c:2393. I have run into this occasionally in the past, which usually forced me to hand edit the .net file, when somehow the VPE corrupted the file. A quick look at the code implies that the error might be a problem with settings for the caching options. Of course, trying to find which node in the graph is the offending one might be tough... Does anyone have any simple suggestions before I trying some harder ideas? Thanks.
Re: [opendx-dev] Image: Options-Undo
I've not seen this problem on AIX, Linux or Windows on various versions since 4.0.9 with either s/w or h/w rendering when playing sequences out of cache, if that's helpful. Jeff Braun [EMAIL PROTECTED]@opendx.watson.ibm.com on 08/10/2001 02:59:52 PM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] Image: Options-Undo At 04:45 AM 8/10/01 -0700, you wrote: Another strange quirk. If you have a volume rendered image up, change the view, and then try to use Options-Undo on the image window to bring back the old view, the image you get is garbage. It comes back instantly so it's apparently not trying to rerender. I think this is related to a problem reported a couple of years ago where cached images will display additional artifacts. On the SGI, if I loop the Sequencer to animate and the images are cached, then strange lines are often present. This was also a problem on Linux, I have not recently checked if the problem still exists there. I recall this was not a problem on all systems. Jeff
[opendx-dev] Re: netCDF import of time series data
Given the discussion led by Nils Smeds about netCDF import, conventions, etc., the following may be of interest. -- Forwarded by Lloyd A Treinish/Watson/IBM on 08/08/2001 12:48 PM --- Brian Eaton [EMAIL PROTECTED]@unidata.ucar.edu on 08/08/2001 12:32:21 PM Please respond to Brian Eaton [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Climate and Forecast (CF) metadata conventions Announcing the beta release of the NetCDF Climate and Forecast (CF) Metadata Conventions. Over the past 2 years there has been an effort to merge the GDT and NCAR CSM conventions for climate and forecast netCDF metadata. Both of these conventions were designed as extensions to the COARDS conventions. The merged convention is simpler and emphasizes both COARDS conformance and backwards compatibility. The new convention is linked to Unidata's netCDF conventions page at http://www.unidata.ucar.edu/packages/netcdf/conventions.html. The following is the abstract from the convention document: This document describes the CF conventions for climate and forecast metadata designed to promote the processing and sharing of files created with the netCDF Application Programmer Interface [NetCDF]. The conventions define metadata that provide a definitive description of what the data in each variable represents, and of the spatial and temporal properties of the data. This enables users of data from different sources to decide which quantities are comparable, and facilitates building applications with powerful extraction, regridding, and display capabilities. The CF conventions generalize and extend the COARDS conventions [COARDS]. The extensions include metadata that provides a precise definition of each variable via specification of a standard name, describes the vertical locations corresponding to dimensionless vertical coordinate values, and provides the spatial coordinates of non-rectilinear gridded data. Since climate and forecast data are often not simply representative of points in space/time, other extensions provide for the description of coordinate intervals, multidimensional cells and climatological time coordinates, and indicate how a data value is representative of an interval or cell. This standard also relaxes the COARDS constraints on dimension order and specifies methods for reducing the size of datasets. We invite comments from the community on this beta release. Brian Eaton, NCAR Jonathan Gregory, Hadley Centre, UK Met Office Bob Drach, PCMDI, LLNL Karl Taylor, PCMDI, LLNL Steve Hankin, PMEL, NOAA
Re: [opendx-dev] netCDF import of time series data
Let me try to get back to your responses to my earlier post. 1. There's no magic here. Essentially netCDF is only an API for self-describing multi-dimensional (scalar) arrays. (I know something about this idea because it's derived from work I did over 15 years ago.) As a data model and an API this is both good and bad. The good is its simplicity. (The concept is easy to use and flexible.How are the arrays are used is an exercise left to the programmer.) The bad is its simplicity. (No inherit support for more complex data. How are the arrays are used is an exercise left to the programmer.) But the descriptions as global and local attributes are sufficiently flexible to define semantics via conventions for to interpret the arrays in an application. The netCDF web site discusses several conventions, including those that the DX importer currently understands as well as others (e.g., COARDS), which are more aligned with the way people typically use netCDF. 2. Well, it certainly would be more convenient for a user to have (general) Import do this. If you look at the code for CDF import within Import, you can see that the concept has already been implemented to some extent, but not for netCDF. For data in netCDF that I use regularly, there are some very specialized conventions. So, it was easier and more effiicent for me to write custom code used in filters and macros, for example, to import the data in the way that I needed. I also wrote some code for importing CDF attributes without the data a long time ago (i.e. also to support user selection prior to import). But again, it's the same idea. 3. I saw your earlier post on this. 4. That's good. I tend to use ncdf for historical reasons or with some codes that use their own naming conventions (i.e., with date/time tags). So, I never checked this. 5. That bug was reported in 1997 with version 3.1.4B (commercial DX). I don't think it was ever fixed. It probably dates from much earlier than that. I hope this helps. Nils Smeds [EMAIL PROTECTED]@opendx.watson.ibm.com on 07/18/2001 07:58:20 PM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] netCDF import of time series data What would be nice is to write it so that the module gets independent of fixed sizes (other than DX limitations). This would require a more thorough rewrite to make sure that memory is freed and allocated consistently and pointers kept sane. What I did was a minimal change to the module to have it work correctly for a set of netCDF files that the documentation says the module can handle. It would be great if the last version (#3) of the patch I wrote made it into the official OpenDX as it is really only a bug fix. I'd appreciate if anyone who is a OpenDX maintainer commented on my suggestions and pointed out any problems they have with it so that I can make necessary modifications. [EMAIL PROTECTED] said: DX supports an arbitrary number of almost arbitrarily named attributes per object (like a series group, or each field, etc.). (almost as there are a few keyword attributes). So you might consider creating a metadata set instead of truncating. The first attribute would declare the number of attributes to follow, then as many as you need to transfer the needed info from netCDF to DX. You can retrieve these within DX with the Attribute module for display. Your decision on how to cut the long string up. My intention at this point was to make the minimal amount of changes needed to get the module working more correct. The only thing that gets truncated at this point (I think, I don't yet understand all the code in the module) is name of attributes and single word attribute values. These are now truncated to 128 characters, which is the same as the netCDF limit of NC_MAX_NAME. Another limitation is MAXATTRSTR(=16) in import_ncdf.c, which I have not yet quite understood what implications it has. With my patch I have successfully read in a netCDF file with three series each with 200 series positions and each field consisting of a scalar float field at 2145 points. And that is on a 300 MHz PC with 128 MB of RAM. That makes me _very_ happy. The limitation with MAXATTRSTR is that if there are more than MAXATTRSTR tokens between two ; in a multiple word attribute value they will not all be parsed, but the latter one gets discarded. I don't know if that is a problem. The multiple word attributes are pre-defined in the User's Reference and are the global attributes that connects variable names to a series. I still now too little about DX in general and DX internals in particular to fully understand how to create metadata and what consequences it might have on backward compatibility of the netCDF import module. What I mainly want is a to get the module to work as described in the documentation ;-) while not breaking any exisiting user's networks. [EMAIL PROTECTED]
Re: [opendx-dev] netCDF examples anyone?
There are a few sample netCDFs from the old DX bonuspak CD (about 5 years old). They are also on-line at: http://www.research.ibm.com/dx/bonuspak/html/bonuspak224.html http://www.research.ibm.com/dx/bonuspak/html/bonuspak247.html http://www.research.ibm.com/dx/bonuspak/html/bonuspak285.html I could also send you some. As to that bug, you would not have seen it posted on the opendx mailgroups since it was reported in 1997 with an earlier (commercial) version (3.1.4B). Nils Smeds [EMAIL PROTECTED]@opendx.watson.ibm.com on 07/24/2001 12:23:21 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: [opendx-dev] netCDF examples anyone? I thought about doing a re-haul of the netCDF import module. The changes I intended to do are the following: - Change from netCDF2 calling convention to netCDF3 - More informative error messages using the netCDF3 error report facilities - Have a look at the possible duplication stuff if it is still there [EMAIL PROTECTED] said: There was a bug reported in netCDF import that it duplicates positions, connections and neighbors in groups. I don't know if it was ever fixed, but it sounds like the problem that was reported earlier this week. Would this be appreciated by anyone or would I be fighting windmills? What would be nice is if anyone who has the examples of netCDF examples in the Users Guide (file:///usr/local/dx/html/pages/usrgu068.htm#HDRCDFSER). I.e. the netCDF file for Partially Regular Grids and Time Series (ocean circulation model) and Irregular Surface (teapot8.ncdf) and maybe corresponding networks as well? If there are restrictions as to how they can be distributed, maybe I can get the actual files outside the list? /Nils -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nils Smeds HPCSU / Sci Techn. e-mail: [EMAIL PROTECTED] UNSW, NSW 2052Voice: +61-2-9385 6915 SydneyFax:+61-2-9385 AUSTRALIA Office: Red Centre, West, Rm 2075 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nils Smedshttp://www.pdc.kth.se/ Center for Parallel Computers e-mail: [EMAIL PROTECTED] Royal Institute of Technology Voice: +46-8-7909115 KTH Fax:+46-8-247784 S-100 44 Stockholm, SwedenOffice: OB2, room 1546 ---
Re: [opendx-dev] problems with 4.1.3 on Linux
You may be right. I'll ask them. I had heard about problems with 7.0, e.g., that there are some kernel conflicts on 7.0 http://faqs.lokigames.com/faq.php3?view=allproduct=GL40 http://www.evil3d.net/articles/linux/howto/nvidia/redhat7/ Unfortunately, I can't seem to get at the patches that they imply exist, assuming that's the problem. However, I have the opendx 4.1.0 rpm using the previous version of the nvidia drivers working just fine on one system, but core dumping on another 7.0 system with the current nvidia drivers. When I try 4.1.3 on a 7.0 system with the previous nvidia drivers it works, leading some credence to the suggestion of a conflict (and now having at least one workaround). Thanks. David Thompson [EMAIL PROTECTED]@opendx.watson.ibm.com on 07/23/2001 02:43:36 PM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] problems with 4.1.3 on Linux You might send a note to the Nvidia guys and see if they can offer a suggestion. It appears that it is an Nvidia extension within GL. Now the version I provided is for Redhat 7.1 and is using Nvidia's drivers for 7.1--that may be a problem. David I just installed the opendx-4.1.3-1.i386.rpm that Dave provided on a RH7.0 system (933 MHz PIII, nVidia GeForce2 MX) with the lastest version of nVidia drivers OpenGL drivers. It all went smoothly. However, when I got to execute dx, both the ui and exec complains /usr/local/dx/bin_linux/dxui: error while loading shared libraries: /usr/lib/libGL.so.1: undefined symbol: __glNVIsWorkstationStereoEnvironment /usr/local/dx/bin_linux/dxexec: error while loading shared libraries: /usr/lib/libGL.so.1: undefined symbol: __glNVIsWorkstationStereoEnvironment Any simple suggestions? When I tried the 4.1.0 rpm on this same system, both the ui and exec core dump. However, 4.1.0 is working fine on another 7.0 system I have (500MHz PIII, nVidia Quadro). Thanks. -- . David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
[opendx-dev] problems with 4.1.3 on Linux
I just installed the opendx-4.1.3-1.i386.rpm that Dave provided on a RH7.0 system (933 MHz PIII, nVidia GeForce2 MX) with the lastest version of nVidia drivers OpenGL drivers. It all went smoothly. However, when I got to execute dx, both the ui and exec complains /usr/local/dx/bin_linux/dxui: error while loading shared libraries: /usr/lib/libGL.so.1: undefined symbol: __glNVIsWorkstationStereoEnvironment /usr/local/dx/bin_linux/dxexec: error while loading shared libraries: /usr/lib/libGL.so.1: undefined symbol: __glNVIsWorkstationStereoEnvironment Any simple suggestions? When I tried the 4.1.0 rpm on this same system, both the ui and exec core dump. However, 4.1.0 is working fine on another 7.0 system I have (500MHz PIII, nVidia Quadro). Thanks.
Re: [opendx-dev] netCDF import of time series data
Actually, this reminded me of a few things about netCDF import in DX from many years ago: 1. There is some support of metadata import (attributes in both the DX and netCDF sense), but it is limited. There is more in CDF import, for example. This is an area that if someone is interested could use enhancement. In particular, there are some conventions that have been established among different sets of netCDF users for metdata to help with data exchange and applications building.. A netCDF following that convention can be dentified by having the global attribute, Conventions with the value of COARDS, for example. These conventions are essentially semantics for higher-order constructs beyond multi-dimensional arrays, which are handled natively within DX. Thus, it's a clear match. Essentially, there is a mechanism to describe coordinates/mesh as a product specification (e.g., lat, lon, pressure), fill and missing values, array ordering, time, units, etc. Currently, Import can read such a netCDF, but cannot associate the positions information with the data, and the attributes are not Import'd at all. If one looks at the netCDF independently of DX, one can extract the metadata and construct the fields appropriately by hand (or by writing a custom program or script which can imports the information separately). Unidata, the purveyor of netCDF, maintains a repository of such conventions. Since DX has a useful set of netCDF conventions, they can be included in this repository by simply supporting the global Conventions attribute with a value of DX. Once this is done, Unidata should be contacted. so they can reference the DX conventions for their users. They do point to OpenDX for their users currently. 2. Along the lines of 1., being able to import netCDF attributes without the data would be useful to create metadata-driven applications with the overhead of reading data. 3. netCDF import was designed around a nearly-decade-old version. There has been some enhancement since from Unidata. 4. netCDFs often go by the extension of .nc or occasionally .ncdf, but the former is the preferred one. Import doesn't know about that extension. 5. There was a bug reported in netCDF import that it duplicates positions, connections and neighbors in groups. I don't know if it was ever fixed, but it sounds like the problem that was reported earlier this week. Chris Pelkie [EMAIL PROTECTED]@opendx.watson.ibm.com on 07/18/2001 07:29:51 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] netCDF import of time series data I don't used netCDF so won't be looking at the patch (which does come through to me), but a thought. DX supports an arbitrary number of almost arbitrarily named attributes per object (like a series group, or each field, etc.). (almost as there are a few keyword attributes). So you might consider creating a metadata set instead of truncating. The first attribute would declare the number of attributes to follow, then as many as you need to transfer the needed info from netCDF to DX. You can retrieve these within DX with the Attribute module for display. Your decision on how to cut the long string up. Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED]
Re: [opendx-dev] netCDF import of time series data
Keep in mind that dx -memory n, only give n MB available to dx. 32 MB would be barely enough to get the exec going. In addition, the exec uses 32-bit addressing. So, you can only give 2 GB to the exec, unless Greg has changed this in a more recent release. I use much larger meshes from netCDFs without problem on AIX, Linux and Windows. I typically read one time step at time. The data are on irregular positions and regular connections (quads or cubes). But since the mesh is constant, I read that in once and cache it. Subsequent reads replace the data component, which is more efficient. Granted, the size of your data should easily fit in memory. NetCDF certainly doesn't do anything to be conservative of storage except having a simple notion of what DX calls product arrays. Nils Smeds [EMAIL PROTECTED]@opendx.watson.ibm.com on 07/16/2001 10:34:38 PM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] netCDF import of time series data By default a series is loaded into memory all at once so you could be definitely outstripping available resources once you enlarge your series. I am aware of that, but this is a time series of 6 time steps where each time step is a scalar field on 64x32 points. The positions are the same for all fields and connected through the same quad connection throughout. This is a total of ~200k of data in the raw netCDF file. Even though it blows up inside the visualizer due to the extra information you need to keep available it still seems odd that it does not work on a system with 6GB of RAM. In fact, I now repeated the test using a 6x6 mesh instead and the import module crashes if I have 6 time steps, but works ok when I have 5 time steps. Admittedly, this was on a 128 MB linux system and using the command line: dx -memory 32 -local -host localhost But this same system and command line happily displays an 8x8x8 3D mesh and the 64x32 mesh provided the time series is no longer than 5 time steps. I am by no means ruling out that I am doing something wrong. Possibly in the structure of my netCDF file. But I don't believe it is a system resource issue. Anyway, thanks for the input. I'd be more than thankful if anyone could find out where the problem lies. Cheers, /Nils -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nils Smeds HPCSU / Sci Techn. e-mail: [EMAIL PROTECTED] UNSW, NSW 2052Voice: +61-2-9385 6915 SydneyFax:+61-2-9385 AUSTRALIA Office: Red Centre, West, Rm 2075 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nils Smedshttp://www.pdc.kth.se/ Center for Parallel Computers e-mail: [EMAIL PROTECTED] Royal Institute of Technology Voice: +46-8-7909115 KTH Fax:+46-8-247784 S-100 44 Stockholm, SwedenOffice: OB2, room 1546 ---
Re: [opendx-dev] vector rendering for postscript output
The place to look is in the Export module, which is where such a capability should go. Export dumps the content of DX objects to disk file(s) in various formats. Only one of the formats (the native dx format) supports all of the different types of objects that the DX data model handles. One of the supported formats is VRML, which only makes sense for a geometric subset of the DX data model. That code may serve as a good place to start since you would have to process the input objects in a similar fashion prior to encoding in Postscript instead of VRML. This approach would be more general-purpose and independent of rendering. It also would be easier than trying to modifying the hardware rendering to utilize the approach with gl scenes that you cited. Once you have parsed the description of geometry in DX (i.e., following what is done for VRML), you could use some of the same ideas that Kilgard does for the Postscript encoding. Andreas Klaedtke [EMAIL PROTECTED]@opendx.watson.ibm.com on 06/12/2001 08:39:30 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: [opendx-dev] vector rendering for postscript output Hi, as I am new to this list but could not find any word about this topic in the mailing list archives, maybe someone could give me a hint or a clarification: as I have realized it, there does not exist a possibility to export scenes in a vectorized format for resolution independent output. The postscript output as it exists does result in a rasterized bitmap image. Now the suggestion/question: Did anybody think of doing something similar to the way Mark Kilgard did vector postscript output for gl scenes? http://reality.sgi.com/opengl/tips/Feedback.html There was also a recent reference in http://www.opengl.org about a c library which refines the OpenGL Feedback Ansatz with a sorted BTree. If this Ansatz would be possible, where should I start with inserting this OpenGL wrapping? I am not very familliar with the code base although I have compiled it on several platforms. -- Andreas Klaedtke DLR Stuttgart Institut fuer technische Physik Theoretische Quantenelektronik Pfaffenwaldring 38-40 D-70569 Stuttgart Fon: +49(0)711-6862 737 Fax: +49(0)711-6862 349 Email: Andreas Klaedtke [EMAIL PROTECTED] [EMAIL PROTECTED] (private)
Re: [opendx-dev] vector rendering for postscript output
The print image/save image in the Image window invokes the WriteImage module, which receives a bitmap from the Render module. That bitmap is software-rendered whether hardware (OpenGL) rendering is being used or software rendered is set (unless Greg made changed this in a more recent version). What you suggest would be harder in DX. Andreas Klaedtke [EMAIL PROTECTED]@opendx.watson.ibm.com on 06/12/2001 10:24:08 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: [opendx-dev] vector rendering for postscript output Ok, I thought of something easier. Could you describe why it would'nt be possible to just add something similar to the print menu command from the image window? Just set up the postscript output, call the gl drawing sequence and close the postscript output? On 12-Jun-01 Lloyd A Treinish wrote: The place to look is in the Export module, which is where such a capability should go. Export dumps the content of DX objects to disk file(s) in various formats. Only one of the formats (the native dx format) supports all of the different types of objects that the DX data model handles. One of the supported formats is VRML, which only makes sense for a geometric subset of the DX data model. That code may serve as a good place to start since you would have to process the input objects in a similar fashion prior to encoding in Postscript instead of VRML. This approach would be more general-purpose and independent of rendering. It also would be easier than trying to modifying the hardware rendering to utilize the approach with gl scenes that you cited. Once you have parsed the description of geometry in DX (i.e., following what is done for VRML), you could use some of the same ideas that Kilgard does for the Postscript encoding. Andreas Klaedtke [EMAIL PROTECTED]@opendx.watson.ibm.com on 06/12/2001 08:39:30 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: [opendx-dev] vector rendering for postscript output **snip old message** -- Andreas Klaedtke DLR Stuttgart Institut fuer technische Physik Theoretische Quantenelektronik Pfaffenwaldring 38-40 D-70569 Stuttgart Fon: +49(0)711-6862 737 Fax: +49(0)711-6862 349 Email: Andreas Klaedtke [EMAIL PROTECTED] [EMAIL PROTECTED] (private)
RE: [opendx-dev] DX on W2k
I run it on a few dual processor machines under NT 4.0. Suhaib's previous version did as well as did the commercial version. I've not tested it on a dual processor with Win2K. Obviously, the exec onlys runs serially, but NT does a fair job of keeping the exec on one cpu and the ui on the other... Suhaib Siddiqi [EMAIL PROTECTED]@opendx.watson.ibm.com on 04/05/2001 01:41:57 PM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: 'opendx2-dev@lists.berlios.de' opendx2-dev@lists.berlios.de cc: Subject: RE: [opendx-dev] DX on W2k I have not tested it on a dual processor CPU. Have you? Suhaib -Original Message- From: Chris Pelkie [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2001 12:38 PM To: opendx2-dev@lists.berlios.de Subject: RE: [opendx-dev] DX on W2k OK, I modified the editor.bat to do dx -script which should launch the dxexec. Running from the DOS shell, I see Starting DX executive Open Visualization Data Explorer More info... blah blah Version - 4.1.1 Error during initialization getmem can't commit memory cannot initialize DX library C:\opendx\bin This is a dual 300Mhz Pentium (Dell 410) with 1Gb of RAM and 1.5Gb page space on C and 3Gb page space on D. As mentioned, W2K was just installed (clean) a couple days ago, so it's certainly possible that there is some config item that isn't right. Any other ideas of things I can check or try? Thanks. Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED]
