VMD-L Mailing List

From: Vlad Cojocaru (Vlad.Cojocaru_at_eml-r.villa-bosch.de)
Date: Thu Jul 13 2006 - 03:57:28 CDT

HI John, Alex,

Thanks a lot for your answers. Of course I considered Alex's suggestion
even before I wrote my email and its probably the most elegant way to
deal with this problem. I was just curious to see if there isnt a way to
do it directly in VMD but probably Alex in right and if I hack the code
I might get into other problems ...

This 9999 problem is also in pdb files written by Leap or ambpdb in
Amber ... and it becomes a problem when one wants to keep waters lets
say 5A around the system and then use these waters for a new run ...
Then Leap will complain about duplicate atoms and thus I cannot use all
the waters I need... Of course this is a Leap problem but I thought that
maybe one can solve this by writing pdbs using VMD.....

I will write my own scripts to renumber the residues...

Thanks again
vlad

Axel Kohlmeyer wrote:

> On 7/12/06, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> hi vlad,
>
>> Vlad,
>> Even if you hack the PDB plugin to avoid writing out the chain
>> identifier, other programs may not be able to read the resulting
>> file since many depend on the strictest adherance to the PDB file
>
>
> this is an often underestimated point. you may get away with
> a hacked version of pdb for one tool, but it may fail badly with
> the next. the only _consistent_ way of handling it, is to try and
> stay as close as possible to the standard. the general rule for
> reading writing 'standard' formats is: be permissive on reading
> and strict on writing. unfortunately, not all programs adhere to it.
>
>> format specification. The PDB plugin supports reading of various
>> illegally formatted PDB files as a result of many MD packages writing
>> such files for macromolecules with more than 99,999 atoms and thousands
>> of waters, for example. Readding such files into other packages
>> is hit and miss, and you can't blame them for not reading them since
>> they do indeed violate the PDB format spec. The strategy that
>> the PDB plugin is employing once it runs out of the 9999 legal
>> residue number limit, is to begin emitting hexadecimal numbers.
>> When we exhaust the limit of hexadecimanl numbers, then we begin
>> printing asterisks for the residue numbers e.g. "****". If you want
>> to alter the behavior of the PDB plugin with regard to these
>> out-of-spec files, you can simply change the readpdb.h code and
>> modify the write_raw_pdb_record() routine therein, increase the
>> plugin version number, recompile, and then load into your VMD and
>> you can have it do anything you like. If Leap has an alternative
>> way of dealing with PDB files containing > 9999 residues, let me know...
>
>
> since VMD has a 'predictable' way of handling it, i suggest you write
> a small filter program (in awk, perl, python, tcl...), that converts
> those
> illegible 'numbers' to something leap can read and apply it, _after_ you
> have generated the files with VMD. since you only want to look at rather
> small chunks of the system, a renumbering would not hurt, right?
> this way you retain consistent behavior of VMD and get files that work
> with leap.
>
> axel.
>
>>
>> John Stone
>> vmd_at_ks.uiuc.edu
>> 

-- 
Dr. Vlad Cojocaru
EML Research gGmbH
Molecular and Cellular Modeling Group
Schloss-Wolfsbrunnenweg 33
69118 Heidelberg, Germany
Phone: +49-6221-533266
Fax: +49-6221-533298
e-mail: Vlad.Cojocaru_at_eml-r.villa-bosch.de
http://projects.villa-bosch.de/mcm/people/cojocaru/