The natom in the coordinates file (inpcrd/restart) is written by x/tleap in
an i5 field, and read by sander the same way. The natom field in the prmtop
file is written and read as an i6 field. Thus, the coordinate natoms value
can overflow with over 99,999 atoms. This is pretty easy to fix if you
write code (modifying x/tleap and sander to use an i6 natom field in the
coordinate file, and then you are good out to about 300,000 atoms or so.
Then you will hit other problems that crash sander; don't know whether it is
internal overflows or what. The number of excluded atoms in prmtop is a
likely candidate for overflow, but not at 500,000 atoms where I have
observed problems.
Good Luck - Bob Duke
----- Original Message -----
From: "Ling Zhang" <lz267_at_nyu.edu>
To: <amber_at_heimdal.compchem.ucsf.edu>
Sent: Friday, June 14, 2002 10:58 AM
Subject: The atom number mismatch in coord and topology file in AMBER6.
> Dear all,
> >
> >
> In AMBER6, when I carried out minimization while holding a part of
> the system restrained, the mdout file showed that the atom number is
> mismatched in constraint coord and topology files. But the toltal atom
> number displayed in the coord and topolygy files were the same 103250.
> The coord file and topolygy file were generated from Leap which worked
> well when I generated the coord and topology files for the other small
> system.
> > Is it possible that Leap will give wrong coord and topolygy files
> when the system is big, such as 103250 atoms in my case? Then how to
> fix it?
> > Thanks a lot.
> >
> > Ling
> >
> P.S. Sorry for forgeting to say it's in the AMBER6 in the last mail.
>
>
>
Received on Fri Jun 14 2002 - 09:27:00 PDT
