Date: Sun May 31 2015 - 07:43:34 CDT
I have played with this a bit more and found that apparently CHARMM converts atom types from RTF and PRM files to upper case while the ones from the PSF are taken as is ... ouch! Anyway, what I am coding now is a converter from AMBER prmtop to the CHARMM formats. So I have to prefix GAFF types (or any other with lower case letters) to not accidentially create the same names as in the "main" force fields.
I also counter-check with NAMD. I found one issue with atom type names of the newer AMBER force fields starting with a digit, e.g. "3C" (I had this also with GROMAC's grompp BTW). NAMD tries to distinguish XPLOR from CHARMM format by scanning for digits in the atom type "name". This is done via a scanf "%d" which will be succesful for a string starting with a digit as it should be but gives a false error in this case. But one might ask why to use the AMBER force fields through conversion to PSF anyway...
From: Jason Swails [jason.swails_at_gmail.com]
Sent: 28 May 2015 19:55
To: namd-l_at_ks.uiuc.edu; Loeffler, Hannes (STFC,DL,SC)
Subject: Re: namd-l: atom types in PSF/PRM/RTF
On Thu, 2015-05-28 at 19:19 +0100, Hannes Loeffler wrote:
> Many thanks. But I think it goes without question that there needs to
> be internal consistency between the files.
> Anyway, I have looked through the source of c38b1 and the character
> lenghts of atom types are A4 in the traditional format and A6 in the
> extended format. The data type is CHARACTER which I would expect to be
> ASCII but maybe there are differences with different compilers. In any
> case, this should, in principal at least, give a wide range of possible
You can also check top_all36_cgenff.rtf and see that there are plenty of
atom types longer than 4 characters:
MASS 263 HGAAM0 1.00800 ! aliphatic H, NEUTRAL trimethylamine (#)
MASS 264 HGAAM1 1.00800 ! aliphatic H, NEUTRAL dimethylamine (#)
MASS 265 HGAAM2 1.00800 ! aliphatic H, NEUTRAL methylamine (#)
As Josh mentioned, the PSF file supports an "EXT" flag which expands the
width of the atom type and serial number fields to accommodate lots of
atom types and atoms.
As for the Fortran "character" type, it is an ASCII character (or, more
precisely, a 1-byte character) by default. Lots of programs depend on
this property for proper data alignment, so you can be pretty confident
that all compilers obey this.
I think you can give character a "kind" (like with other variable types)
to support other encodings, like UCS or UTF-8. But you would need to
see something like
character(kind=SELECTED_CHAR_KIND('utf-8'), len=10) :: len10_string
All the best,
-- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher
This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:21:54 CST