Re: NAMD trajectory format

From: Axel Kohlmeyer (
Date: Fri May 30 2008 - 08:29:26 CDT

On Fri, 30 May 2008, Peter Freddolino wrote:

PF> On a related note, I know that someone had wrapped the catdcd 3.0 readers
PF> for python (; a similar python wrapper
PF> for the molfile plugins would probably be the ideal solution to this and
PF> many other problems.

if i'm not totally mistaken, the next version of VMD should
be importable as a python module. that would give that
feature in pythong for free and a ton of others...


PF> Best,
PF> Peter
PF> Axel Kohlmeyer wrote:
PF> > On Thu, 29 May 2008, Konrad Hinsen wrote:
PF> >
PF> > KH> On May 28, 2008, at 16:05, Axel Kohlmeyer wrote:
PF> > KH>
PF> > KH> >it is not that difficult and you could use the fortran wrapper code
PF> > KH> >that i contributed as a starting point. OTOH, you can also just link
PF> > KH> >the individual subroutines as a static library. see:
PF> > KH> >
PF> > KH> >
PF> > KH> >
PF> > KH> >and particularly:
PF> > KH> >
PF> > KH> >
PF> > KH>
PF> > KH> Thanks, I will look at that for use in the future. For my current
PF> > KH> needs, I
PF> > KH> am quite happy with my DCD parser written in Python, which seems to
PF> > KH> work
PF> > KH> fine, at least for the one trajectory that I have for testing.
PF> >
PF> > dcd trajectories are nasty to parse in general because they are fortran
PF> > unformatted. depending on whether the file was written on a machine
PF> > with the same or different endianness and a (64-bit) compiler that uses
PF> > either 32-bit (most) or 64-bit (some versions of gfortran and g95,
PF> > depending on flags) record markers and 64bit default integers
PF> > you get a different file. john has put a lot of effort into making
PF> > the dcd reader in molfile particularly flexible and efficient.
PF> >
PF> > there is a lot of convenience in writing your own stuff, but it also
PF> > adds inconsistencies (just look at how many broken/non-compliant .pdb
PF> > format writers and readers there are). with computational tools becoming
PF> > increasingly ubiquitous in our research it is high time to consolidate on
PF> > a few tools/libraries and use and improve those instead of re-inventing
PF> > the same old wheels over and over again.
PF> >
PF> > that is why, for instance, i wrote those fortran wrappers to molfile.
PF> > instead of adding just one more file formats to the (fortran based)
PF> > analysis code of a colleague, i added _all_ the formats that molfile
PF> > supports and any future file format work from me can focus on improving
PF> > the molfile library. this in turn
PF> > will also help every other project that uses it at the same time.
PF> >
PF> > cheers,
PF> > axel.
PF> >
PF> > KH> Thanks again for your help,
PF> > KH> Konrad.
PF> > KH>
PF> > KH> PS: If anyone wants a copy of my DCD parser in Python, just ask!
PF> > KH> --
PF> > KH> ---------------------------------------------------------------------
PF> > KH> Konrad Hinsen
PF> > KH> Centre de Biophysique Moléculaire, CNRS Orléans
PF> > KH> Synchrotron Soleil - Division Expériences
PF> > KH> Saint Aubin - BP 48
PF> > KH> 91192 Gif sur Yvette Cedex, France
PF> > KH> Tel. +33-1 69 35 97 15
PF> > KH> E-Mail:
PF> > KH> Web:
PF> > KH> ---------------------------------------------------------------------
PF> > KH>
PF> > KH>
PF> > KH>
PF> >
PF> >

Axel Kohlmeyer
   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.

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:49:31 CST