VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_cmm.chem.upenn.edu)
Date: Thu May 07 2009 - 09:44:06 CDT

dear pawel,

> Vorgive me complaints, I do really like VMD and I appreciate the hard
> work of the developers. But since I like Python too, I would gladly see
> improvements in VMD Python API, and therefore I am reporting odds I've
> bumped into ;-)
> And there are a couple more:
>  - VMD.atomsel.atomsel(text_selection, molid=#)
>   always selects from top molecule, ignoring molid.
>  - the following code fails (M is a VMD.Molecule.Molecule instance):
>     Mreps = M.reps()
>     M.clearReps()
>     for rep in Mreps: M.addRep(rep)
>   The reason is that every rep keeps a back reference to M even after
>   M.clearReps(), so one must add e.g.:
>     for rep in Mreps: rep.remove_molecule(M.id)
>
> Sadly enough, I think the Python interface in VMD has less functionality
> and more bugs than the Tcl due to smaller user base. This situation

before going any further, i'd like to put a disclaimer here. i am speaking
for myself and reporting my own observations and not those of the VMD
maintainers, even though i've contributed and am contributing code actively
to the VMD codebase.

it is not (only) the smaller user base, it is the lack of developers that
makes the python interface lagging behind the tcl one so much.
there are a bunch of items to take into consideration here.

it is generally not an easy situation to have two script interpreters interfaced
to a code. how do you make certain that both are "seeing" the same state.
tcl has an advantage, as it came first.

on top of that, there is the issue that python script interfaces are a double
edged sword: they make it extremely easy to add functionality to a package
and one can write complex code with surprisingly little effort and
much convenience.
but that is bought with an enormous complexity at maintaining those codes
and particularly the so-called "dependency hell". since it is almost too easy to
write python wrappers, there are a lot and they are of different
quality and differently
well maintained. as a consequence, keeping everything in sync _and_ maintaining
it across multiple platforms can quickly turn into a nightmare. the advent of
64-bit x86 made it even worse.

one of the nastiest quirks, for example is providing tkinter support. tkinter
uses tcl/tk, vmd uses tcl/tk. if you want to use VMD with tcl/tk and python
(with tkinter) then you better make certain that tkinter uses the same tcl/tk
that VMD uses. now different distributions and versions of them ship with
different versions of tcl/tk and python and combinations thereof,
other platforms
don't ship with python or tcl/tk at all. compiling VMD is non-trivial for most
users, so the only way to ship a portable binary is to include the runtime, and
that means also python _and_ all packages that it loads. now compiling all
packages _and_ its dependencies on all platforms in a consistent way is a
quite a bit of work. if i was the maintainer of VMD i'd have long ago put out
the request to have with interest in keeping the python interface in VMD alive
own up to it or have it removed. john is too nice a person to this, so
no worries.
i had to take a deeper look into the python support code in VMD a while ago
and was puzzled to find effectively 3 different levels or types of an API that
can be compiled and used all at the same time (with some tweaks) and there
is now even the option to compile VMD as a python module to be incorporated
into other interpreters (it works, i have been able to do so with the
HOOMD code).

but as you already noted, the whole interface is overdue for a serious overhaul,
an update of the documentation and some systematic regression testing and
giving some serious thought on how to maintain this in this in the future and
keep it maintainable. these are all tasks that would take a significant chunk of
work. in our current "result-oriented" world of research, it is
difficult to find people
willing to invest time into this.

> is probably going to persist as new users or new projects choose the
> better supported and documented interface, with many examples around.

see my arguments above. people will write stuff in what works for them.
the whole nature of open source is that people can work on what itches them
the most. obviously, there are not enough people around that have the "python
itch" badly enough to make it happen (or are too result oriented and 'suffer'
through tcl instead).

> For example, I don't see a single Extension plugin written in Python, at
> least in the standard VMD package.  Although the API was probably there
> for years, it may possibly be mostly untested. And even a single example
> would be helpful for programming users to start playing with.

don't hesitate. write some and contribute them.

> But the probably most important obstacle for potential writers of
> Python plugins is that the standard Python library and Numeric are
> external to VMD, which means that for most users they are likely not
> installed at all.  The old python version and Numeric required by VMD is
> another problem. Numeric is no longer supported and it would be good if
> VMD switched to numpy instead.  I was biten by bugs in Numeric which are

it is done. see above for the reasons why python support is the way it is.

> fixed in numpy. But of course I understand this may be nontrivial, and
> if there is small user base indeed, it means low priority, too.

well, it is a matter of perspective. i'd say that if VMD had a better supported
and documented python interface, there would be much more people using
it, as the average researcher these days seems to be much more familiar
with python than with tcl.

the problem is really that people who want better python support in VMD, have
to become more active and start working on it. it can be in small increments
even and the more of them there are, the less work for each of them.

this is how i got involved into working on VMD. it was not doing things that i
needed to do good enough and i had the choice of either writing my own
tools (i did at some point) or learn how to improve VMD to be able to do
what i want. the choice was ultimately to learn how to add to VMD what i
needed and _then_ go a little bit further to make it as general as possible.
now, even many of the kernels of the tools i wrote outside of VMD have
found their way now into the core of VMD or some plugin.

sorry for the long "lecture", as you can see, i am very passionate on this
subject matter... ;)

cheers,
    axel.

> Cheers,
> Pawel
>
>> > However, the coordinates _are_ affected within VMD: if there are any
>> > Labels, the Labels do shift according to the translation vector or the
>> > transformation applied. Also, when I create a new graphical
>> > representation, it appears in the new position. Therefore I tried to
>> > do:
>> > VMD.molrep.set_autoupdate(molid, rep_num, 1)
>> > prior to moving the molecule, but it didn't help, either.
>> > As it seem to me, the only way to go is to:
>> > 1) delete all representations;
>> > 2) move; and then
>> > 3) create representation(s) again.
>> >
>> > Is there a better way to get the graphical representations to move with
>> > the molecular coordinates, or have I just discovered a bug?
>> >
>> > With many thanks for the great program,
>> > Pawel
>>
>> --
>> =======================================================================
>> Axel Kohlmeyer   akohlmey_at_cmm.chem.upenn.edu   http://www.cmm.upenn.edu
>>    Center for Molecular Modeling   --   University of Pennsylvania
>> Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
>> tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
>> =======================================================================
>> If you make something idiot-proof, the universe creates a better idiot.
>
> --
> --> Paweł Kędzierski    Molecular Modelling and Quantum Chemistry Laboratory
>                        Institute of Physical and Theoretical Chemistry I-30
>                        Wroclaw University of Technology
>                        Wroclaw, POLAND
>
> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey_at_cmm.chem.upenn.edu   http://www.cmm.upenn.edu
  Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.