Seibold, Stephen wrote:
> Hi Ross
> I did try using the CHARMM crd file instead of its pdb file and this seems to work so far. I am no longer get the Fortran error. I am still not sure why the pdb file built by CHARMM was giving a problem.
>
> Anyway, thanks for your idea of using CHARMM crd file instead.
The problem is here due to the fact that chamber is parsing each PDB
line on an element by element basis, where an element is delimited by a
space character, instead of using the Fortran format for that type of
line. See see psf_strings::getwords(),next_word() for the code.
Hence when it comes to a (perfectly valid) line like this in your PDB:
ATOM 1036 HA ASP 65 -46.460 -98.716 -2.252 1.00 0.00 A
ATOM 1037 CB ASP 65 -47.780-100.417 -1.925 1.00 0.00 A
which is:
( A6,I5,1X,A4,A1,A3,1X,A1,I4,A1,3X,3F8.3,2F6.2,10X,A2,A2 )
it cannot tokenise 47.780-100.417 into 47.780 and -100.417 since there
is no space, and thus the error message you see. Using the crd form
should work around this issue. Ideally, the getwords() approach should
deprecated, favouring a specific Fortran format.
On a related note, the use of the PDB format as an intermediate file
format is fragile and error prone. To cite a quick example, I had one
student recently output a system the he'd build in charmm to a PDB with
the command:
open write card unit 1 name foo.pdb
write coor pdb unit 1
close unit 1
This then caused issues in parsing since the atom number I5 field had
overflown:
ATOM 99998 C25 POPC 264 59.670 95.210 39.040 1.00 0.00 POPC
ATOM 99999 H5R POPC 264 58.750 94.750 39.450 1.00 0.00 POPC
ATOM ***** H5S POPC 264 59.660 96.250 39.430 1.00 0.00 POPC
ATOM ***** C26 POPC 264 60.880 94.350 39.390 1.00 0.00 POPC
Using the crd format (write coor card unit 1) resolved this.
Regards,
Mark
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri May 27 2011 - 02:00:03 PDT
