Hi Mark,
Thank you so much for the explanation and hard works!
Regards,
Colvin
On Thu, Mar 3, 2011 at 1:48 AM, Mark Williamson <mjw.mjw.name> wrote:
> colvin wrote:
> > Hi,
> >
> > Thanks for comments.
> >
> > PTRAJ is able to generate pdb from chamber prmtop and inpcrd, BUT with a
> > message on appeared on screen:
> >
> > "WARNING in scanDouble: ...scanning chrg"
> >
> > and in the ptraj.out:
> >
> > PRMTOP does not contain %FLAG TITLE
> >
> > There were errors upon reading parm file!!!
> >
> >
> >
> > As for vmd, the lasted 1.9beta version and earlier version cannot
> understand
> > chamber prmtop, but it can, however understand the file if CTITLE is
> > replaced with TITLE. But, with edited chamber prmtop and later on loaded
> in
> > the inpcrd, the atoms of the system lost their connectivity.
> >
>
> Hi Colvin,
>
> A great place to start in understanding some of the motivations behind
> the field changes in the charmm parmtop file format can be found in the
> AMBERTools manual, specifically from page 33 onwards:
>
> http://ambermd.org/doc11/AmberTools.pdf
>
> Page 34 explains which sections were modified/added and page 37 is the
> reasoning behind the TITLE to CTITLE change. Basically; this was a
> safeguard to stop users of older unpatched versions of SANDER/PMEMD from
> running a CHAMBER generated prmtop file since it would give incorrect
> results, silently. "Hacking" this field back to TITLE will result in
> unforeseen consequences, since, as stated in the manual, other fields
> have had modifications.
>
> At the time when I started to work with the CHAMBER code, I made the
> assumption that all tools that read prmtop files adhered to its self
> describing nature i.e. a reading parser would use the format specifier
> that followed the %FLAG section in the prmtop file:
>
> %FLAG value
> %FORMAT(10I8)
>
> Hence, any format modifications or additional flags would not disrupt
> input parsing. SANDER and PMEMD have the routine nxtsec (
> amber/src/lib/nxtsec.f in SANDER and nextprmtop_section.fpp in PMEMD )
> that does this correctly. More concisely, the content (fmt here) of the
> %FORMAT(fmt) string is passed directly to the read(data, fmt) subroutine
> in FORTAN, hence it knows exactly what form to read in the data. More
> information about the FORTRAN format can be found here:
> http://www.cs.mtu.edu/~shene/COURSES/cs201/NOTES/chap05/format.html
>
> However, later on, I soon found that most of the C and C++ tools that
> read prmtops, ignore the format specifier in the %FORMAT(), using
> instead, hardcoded format values that are a function of the %FLAG value.
> Hence, changing the %FORMAT value of an existing FLAG would cause
> breakage since the following data would be parsed in using the old
> hardcoded value. In addition, some tools are also confused by the valid
> %COMMENT flag as well.
>
> From looking at the differences in FORTRAN's read() subroutine and
> C/C++'s analogous function, scanf(), I realised why this situation
> arose. The scanf() function does not understand FORTRAN's file format
> specification when this is used as a parameter. As a result, I started
> to look around for any C libraries that could read in FORTRAN format,
> but I did not find any.
>
> Next, I started to write a C function that could carry out a translation
> between any given FORTRAN format specifier to the corresponding scanf
> type specifier, with the aim of providing this as library to any C/C++
> code that is reading prmtop files. However, this proved to be too time
> consuming to get it to work for every case.
>
> Next, I looked into the option of linking fortran code that contained
> the nxtsec() subroutine to the C/C++ code. This was a valid option, but
> would add extra compile requirements to a given C/C++ codebase; I don't
> think the VMD people would have appreciated the overhead of installing a
> FORTRAN compiler just to compile one file.
>
> With reference to the errors from ptraj and ambpdb, I never tested these
> with any chamber generated prmtop files and trajectories, but the errors
> you are seeing are because of the situation I just described.
>
> And this is the status quo. There is a library that can do this in Java
> ( http://www.ichemlabs.com/fortranformat ), however, I've yet to find
> something in C/C++ that can do this.
>
> Regards,
>
> Mark
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Mar 03 2011 - 01:30:03 PST
