ECCE 6.3 apps won't start

Jump to page 1Prev 16

Gets Around	4:58:09 PM PDT - Wed, May 2nd 2012 Hi Mike, This is looking like a promising fix. If you have time to try the source code change I mentioned and see if that works for you, that would be great. If you don't have time then on Thursday I'm hoping to get out new distributions for you to try. This fix will let you use your local 64-bit OpenGL libraries instead of the ones distributed with ECCE. Also, I'm updating the ones shipped with ECCE to be standard Mesa OpenGL rather than the NVidia specific ones that just happened to work. Since these will be the same version of OpenGL libraries used by glxgears, at least that will make it a bit more consistent if the StarNet developers end up needing to make a fix. If I really get lucky then this source code fix in ECCE will allow me to build OpenGL from source code like is done for a 32-bit build of ECCE, but not currently for a 64-bit build. Gary

Gets Around	11:00:11 AM PDT - Thu, May 3rd 2012 Mike, There are new ECCE distributions for download with the hopeful fix for the 64-bit OpenGL issue. Both binary distributions and the source code distribution have been updated. Download and install the latest binary distribution and I'm confident you'll be able to run the Builder now using either: 1. The OpenGL libraries shipped with ECCE (no longer NVidia based, but the generic RHEL ones obtained via the yum package manager) 2. Your local OpenGL libraries (you'll need to edit the $ECCE_HOME/siteconfig/site_runtime file and comment out the ECCE_MESA_OPENGL line to use your own local libraries--remember you can edit the $ECCE_HOME/scripts/ebuilder script and temporarily uncomment the ldd line to verify which you are using) 3. OpenGL libraries compiled from the Mesa 6.5.3 distribution bundled with ECCE (you'd need to build the ECCE source code distribution in order to compile these libraries) This resolves the differences between how 32-bit OpenGL and 64-bit OpenGL is handled in ECCE all traced back to that fix in the SGLattice.C code. All associated documentation for building ECCE and the build_ecce script have been updated. The prerequisite check for OpenGL has also been removed since it's no longer mandatory to have OpenGL pre-installed for ECCE since working libraries are now bundled with the distribution and used by default. The one thing I'm not confident about is whether this will resolve your X-Win32 issue displaying OpenGL output on Windows PCs. I have a feeling it won't fix that because you also have this issue with 32-bit ECCE 6.3 binary distribution and all that was done was rationalizing the 64-bit distribution to be equivalent to the 32-bit one. But, it's worth another try and at this point if it doesn't work I can't think of anything else to try on this end. My guess is that what ECCE does with OpenGL is just use more/different features than the glxgears test application does and that is what is causing issues for X-Win32. One thing we do that is more advanced are calls to glReadPixels and glPixelStorei that have to do with reading and writing to the render area that other GL apps don't typically do. Again, I'd spend a bit of time seeing if Cygwin works better for you if you think a solution from StarNet is going to take longer than you want. Gary

Clicked A Few Times	5:27:01 AM PDT - Fri, May 4th 2012 Gary, Sorry I haven't been able to look at this the last couple of days. I read your last few posts, it looks like I should try the latest binary distribution you've made first. I'll do that and let you know. This is not being used for classes, just some researchers want to use, so I'm not under heavy pressure to get it working right away. Mike

Gets Around	11:19:55 AM PDT - Fri, May 4th 2012 Just as well you waited anyway Mike. Try the latest binary distribution and let me know how it works for you. At the very least it should be a better starting point for the StarNet folks because I'd feel strange telling them to debug an issue when the OpenGL libraries being used were for an NVidia hardware card when that card isn't actually present on the host running ECCE. Now it's generic Mesa OpenGL and it's probably just specific features of that ECCE uses that X-Win32 isn't working with. Gary

Clicked A Few Times	12:27:22 PM PDT - Fri, May 4th 2012 Gary, Same result. I think we're as good as we can get with the ECCE setup, and I'll try working with StarNet on X-win32. Thanks for your hard work on this. Mike

Gets Around	12:55:28 PM PDT - Fri, May 4th 2012 Mike, Reading through this thread again I see that an older version of X-Win32 apparently works for you with the latest ECCE 6.3. This was for the 32-bit ECCE distribution at least. Did you also try the old X-Win32 with the latest 64-bit distribution of ECCE? If you get that to work, but the new version of X-Win32 doesn't work, then that seems like a strong case to me to go to the StarNet guys and point this out and hopefully they will agree it's their problem and provide a fix that shouldn't take too long. That their own product once worked should make it much easier for them to figure out what they did wrong or forgot to do with the newest version. Gary

Gets Around	9:26:21 AM PDT - Wed, May 9th 2012 Hi Mike, I keep forgetting to bring this up... Another no-cost option you have for getting ECCE to display to a Windows PC is to install VirtualBox (I personally prefer it to VMware although that would work as well), install your choice of Linux in a virtual machine, and then just ssh back to your Linux box using the VirtualBox/Linux for it's remote X windows display capability. I just tried this with an OpenSUSE Linux virtual machine I happened to have running. No issues at all with remotely displaying the ECCE Builder/Viewer as well as the rest of ECCE. I did need to do an "ssh -X" to enable ssh port forwarding, but other than that, couldn't have been simpler. Finally, this option would also allow users to run ECCE locally on the VM if that is preferred. They could easily access a single ECCE server so only the application software would need to be installed under the VM. So that's a lot more flexibility than X-Win32 offers and all for free. I understand though that since you've already paid for X-Win32, you'd like to have them fix their issue. So maybe this could be an interim solution for you. I would take this approach myself rather than Cygwin for instance. I just didn't think of it originally when you started talking about X Window Servers for PCs since that's what we used as well (e.g. Hummingbird Exceed/3D) before VM technology took over in the past few years. Gary

Clicked A Few Times	10:26:07 AM PDT - Wed, May 9th 2012 Gary, The older X-Win32 does work with the current 64-bit ECCE so I'm leaving it in place. Is it ok if I provide a copy of ECCE to StaNet for them to diagnose this problem? Mike

Gets Around	11:38:26 AM PDT - Thu, May 10th 2012 Mike, ECCE will be released as open source sometime this summer. We're just going through formalities at this point (although it can take a while to get through all of them) before getting final approval to make the release. Until that time people should go through the EMSL user portal (https://eus.emsl.pnl.gov) as documented at http://ecce.pnl.gov/using/download.shtml and complete a software use agreement to get the software. In this case they'd just want a standalone builder binary distribution. Gary

Forum >> ECCE: Extensible Computational Chemistry Environment >> General ECCE Topics

Jump to page 1Prev 16