VMD-L Mailing List

From: Craig Knox (craig.k.knox_at_gmail.com)
Date: Tue Apr 19 2011 - 13:44:42 CDT

Hi John,

In "for_john_stone/mine/single-DGEBA-D230-10K-1.mdf" that I sent in my
last email, I noticed what I think may be another bug in the mdf
reader:

bad resname's when resname + resid is too long

e.g.,

vmd > [atomselect top "index 9000"] get resname
C21H_188¼

(should be same string without the last character)

Where did the last char come from? I'm guessing that this is because
the resname is too long and some weird memory overflow occurred in
sscanf because molfile_atom_t's resname string is not long enough to
hold this many chars + the NULL char...

Looks like it can only handle up to 7 chars and still have room for
NULL (from line 96 of plugins/include/molfile_plugin.h):

char resname[8]; /**< required residue name string */

What are your thoughts?

Thank you very much for your help.

- Craig

On Mon, Apr 18, 2011 at 5:44 PM, Craig Knox <craig.k.knox_at_gmail.com> wrote:
> Hi John,
>
> Sure thing, please see attached tarball.  Most of the examples come
> from the 'msi2lmp' tool, which comes with LAMMPS.  I also included a
> couple of my own car/mdf examples.
>
> Thank you very much for looking into this further.
>
> - Craig
>
> On Mon, Apr 18, 2011 at 5:14 PM, John Stone <johns_at_ks.uiuc.edu> wrote:
>> Craig,
>>  Can you send me a few gzipped MDF files so I can do some local testing?
>> This plugin was originally written in 2003/2004 back when there were still
>> a couple of people on site using InsightII, but since then it hasn't had very
>> much attention other than little bug fixes.  Since nobody here uses
>> InsightII or related software anymore, I don't even have any MDF files
>> available for testing.  If you can send me a few, that'd be very helpful.
>>
>> Cheers,
>>  John Stone
>>  vmd_at_ks.uiuc.edu
>>
>> On Mon, Apr 18, 2011 at 02:03:51PM -0400, Craig Knox wrote:
>>> Dear VMD Developers:
>>>
>>> First of all, thank you very much for such a wonderfully useful and
>>> powerful code!
>>>
>>> FYI, I believe there's a minor bug in the mdf molfile plugin that
>>> causes the element symbol field to be incorrectly used in place of the
>>> atom type (FF) field.
>>>
>>> Here's the relevant piece of code (lines 62-66) from
>>> plugins/molfile_plugin/src/mdfplugin.C:
>>>
>>> static int read_mdf_structure_line(molfile_atom_t *atom, const char *line) {
>>>   // Read pertinent structure information from the line
>>>   if ( sscanf(line, "%[^:]:%s %s %*s %*s %*d %*s %f %*d %*d %*d %f",
>>>               atom->resname, atom->name, atom->type,
>>>               &atom->charge, &atom->occupancy) != 5 ) {
>>>
>>> The sscanf line (line 64) should be changed to:
>>>   if ( sscanf(line, "%[^:]:%s %*s %s %*s %*d %*s %f %*d %*d %*d %f",
>>>
>>> , in order to skip the element field and read the atom_type field instead.
>>>
>>> As an example, here's the beginning of my mdf file:
>>>
>>> !BIOSYM molecular_data 4
>>>
>>> !Date: Wed Jan 12 17:19:39 2011   Materials Studio Generated MDF file
>>>
>>> #topology
>>>
>>> @column 1 element
>>> @column 2 atom_type
>>> @column 3 charge_group
>>> @column 4 isotope
>>> @column 5 formal_charge
>>> @column 6 charge
>>> @column 7 switching_atom
>>> @column 8 oop_flag
>>> @column 9 chirality_flag
>>> @column 10 occupancy
>>> @column 11 xray_temp_factor
>>> @column 12 connections
>>>
>>> @molecule Dendrimer
>>>
>>> LAYE_1:N1           N  n3      ?     0  0    -0.5610 0 0 8 1.0000
>>> 0.0000 C1 C21H_2:C21 C21H_3:C21
>>>
>>> In VMD,
>>>
>>> vmd > set a1 [atomselect top "index 0"]
>>> atomselect1
>>> vmd > $a1 get {index name type element atomicnumber}
>>> {0 N1 N X -1}
>>>
>>> So, the molfile plugin read the 2nd field ('N') as the atom type
>>> instead of the 3rd field ('n3').
>>>
>>> Notice that this bug is likely due to the misleading header/comment in
>>> the mdf file, which says "@column 2 atom_type", although this seems to
>>> be counting from zero, not one (i.e., there's an implicit "@column 0
>>> resname_resid:name").
>>>
>>> Is there any reason to use the element field in place of the
>>> atom_type, or is this a bug?
>>>
>>> Thanks,
>>> Craig
>>>
>>> ---
>>>
>>> Craig K. Knox, Ph.D.
>>>
>>> Computational Materials Science
>>>
>>> U.S. Army Research Laboratory
>>> Materials & Manufacturing Science Division
>>> Macromolecular Science & Technology Branch
>>> 4600 Deer Creek Loop
>>> RDRL-WMM-G, Bldg. 4600, Rm. C237
>>> Aberdeen Proving Ground, MD  21005-5069
>>> 410-306-0856 (phone)
>>> 410-306-0676 (fax)
>>> craig.knox_at_us.army.mil
>>> craig.k.knox_at_gmail.com
>>
>> --
>> NIH Resource for Macromolecular Modeling and Bioinformatics
>> Beckman Institute for Advanced Science and Technology
>> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
>> Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349
>>  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078
>>
>