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
Received on Wed Mar 02 2011 - 10:00:02 PST
