VMD-L Mailing List

From: Cameron Mura (cmura_at_virginia.edu)
Date: Sat May 16 2009 - 22:00:29 CDT

Hi John et al.,

> if you compile from source, and link against your locally installed Python,
> the problem you're having should go away.
>
Thanks for this suggestion....

... I've succeeded in building the plugins directory, Stride and Surf
binaries, and am now ready for the main VMD build... However, I must be
missing something /really/ basic in my understand of the structure of
the code base -- Say my top-level VMD build dir is $VMDDEV/. I built
plugins in $VMDDEV/../plugins (and then had them properly located for
the vmd build via "setenv PLUGINDIR $VMDDEV/plugins; make distrib"... no
problem). What I don't get is that there's not a $VMDDEV/lib dir, even
in a build tree pulled fresh from CVS... This is unlike the, say,
pre-bundled 1.8.6 src, which contains
lib/{cave,fltk,Mesa,points,scripts,stride,surf,tachyon} ?... Of course
the main build attempt (do 'make' in $VMDDEV/src/) then fails, as it
doesn't know where to find the tachyon header files, etc.:
> $] make veryclean && make
> Compiling OpenGLDisplayDevice.C --> OpenGLDisplayDevice.o ...
> Compiling OpenGLExtensions.C --> OpenGLExtensions.o ...
> ...snip...
> ...snip...
> Compiling IMDSimThread.C --> IMDSimThread.o ...
> Compiling CmdIMD.C --> CmdIMD.o ...
> Compiling imd.C --> imd.o ...
> Compiling LibTachyonDisplayDevice.C --> LibTachyonDisplayDevice.o ...
> In file included from LibTachyonDisplayDevice.C:27:
> LibTachyonDisplayDevice.h:28:58: error: tachyon.h: No such file or
> directory
> LibTachyonDisplayDevice.C:35:2: error: #error "LibTachyonDisplayDevice
> requires Tachyon version 0.98.4 or higher."
> ....
> ....
probably missing something really simple ?

thanks again for any advice,
cam

=== John Stone wrote (on 05/16/2009 07:57 PM): ===
> Cameron,
> If you use the pre-built VMD binaries I provide, then you'll need
> the matching Python library that I compiled as well. I haven't posted
> these for download yet as I have to compile on the other platforms
> still, but they will be available in a couple weeks. In the mean time,
> if you compile from source, and link against your locally installed Python,
> the problem you're having should go away.
>
> Cheers,
> John
>
> On Sat, May 16, 2009 at 07:43:18PM -0400, Cameron Mura wrote:
>
>> Hi all,
>>
>> I'm trying to figure out why vmd/python is misbehaving so badly on my
>> fedora 10 (Python v2.5.2) box... I'm currently trying the pre-built
>> v1.8.7beta2.bin.LINUXAMD64.opengl binary. The following is typical of
>> what occurs (I write "typical" because I can get it to misbehave in
>> other ways, depending on version of VMD (1.8.6-vs-1.8.7), Python
>> version, values of PYTHONPATH / PYTHONHOME, etc., but this is the
>> closest to working):
>>
>>> $] vmd -dispdev text -python
>>> Info) VMD for LINUXAMD64, version 1.8.7beta2 (May 13, 2009)
>>> ....snip...
>>> ....snip...
>>> Info) Creating CUDA device pool and initializing hardware...
>>> Info) Starting Python...
>>> Could not find platform independent libraries <prefix>
>>> Could not find platform dependent libraries <exec_prefix>
>>> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
>>> 'import site' failed; use -v for traceback
>>> Traceback (most recent call last):
>>> File "<string>", line 1, in <module>
>>> ValueError: vmdnumpy module not available.
>>> Info) Text interpreter now Python
>>> Traceback (most recent call last):
>>> File "<string>", line 1, in <module>
>>> File "/usr/local/lib/vmd/scripts/python/Tkinter.py", line 59, in
>>> <module>
>>> import _tkinter # If this fails your Python may not be configured
>>> for Tk
>>> ImportError: No module named _tkinter
>>>
>> I'm particularly perplexed by the Tkinter errors because, outside of
>> VMD, the following 3-step test works just fine at popping-open a little
>> Tk widget displaying la cedilla:
>>
>>> $] python
>>> Python 2.5.2 (r252:60911, Sep 30 2008, 15:42:03)
>>> [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> import _tkinter
>>>>>> import Tkinter
>>>>>> Tkinter._test( )
>>>>>>
>>>>>>
>> Both the system-wide and VMD-provided Tkinter modules are imported fine
>> into a bare python session:
>>
>> system-wide:
>>
>>> $] python -c 'import Tkinter; print Tkinter'
>>> <module 'Tkinter' from '/usr/lib64/python2.5/lib-tk/Tkinter.pyc'>
>>>
>> VMD's:
>>
>>> $] setenv PYTHONPATH /usr/local/lib/vmd/scripts/python
>>> $] python -c 'import Tkinter; print Tkinter'
>>> <module 'Tkinter' from '/usr/local/lib/vmd/scripts/python/Tkinter.pyc'>
>>>
>> I've looked at "Python modules within VMD"
>> (http://www.ks.uiuc.edu/Research/vmd/current/ug/node147.html) and
>> google'd around quite a bit, but still not perfectly clear to me what
>> could be the culprit here?... (sidenote: the "Could not find platform
>> dependent(/independent)..." errors above can be overcome by defining
>> PYTHONHOME as /usr/lib64 and PYTHONPATH as
>> /usr/lib64/python2.5/site-packages:/some/place/else/:/blah/blah" in
>> ~/.vmdrc, but the vmdnumpy and tkinter problems persist...) fwiw, I have
>> v24.2 of Numeric installed in a more-or-less standard manner.
>>
>> Any advice or thoughts on this would definitely be appreciated...
>>
>> thanks,
>> cam