topotool and LAMMPS bounding box problem

_Oloriegbe_Suleiman · March 31, 2011, 7:09pm

Axel,

When creating xyz coordinate files from crystallographic data using multiple of lattice parameters (a, b,c) and alpha=beta=gamma = 90 topotool is quite useful for getting a LAMMPS input file, but I have been having problems with the bounding box values xlo, xhi, ylo, yhi , zlo and zhi.

I ran the following on VMD Tkconsole

% pbc set {12.2916 21.0939 29.9379 90.0 90.0 90.0}

% topo writelammpsdata input.coord full

I got the right input.coord file, but topotool listed the serial numbering twice (see data below)

I had to manipulate the file to remove unwanted columns before I could run LAMMPS. I was getting an error that reads

"Incorrect atom format in data file"

These are my questions;

(1) How can I exclude bonds, angles, dihedral and improper types when using the full command

(2) Why am I getting double serial numbering in the LAMMPS file which is the cause of the error.
How can I eliminate this without resorting to modifying the output file every time. Is it possible that
I am using an old version of topotool that comes with VMD?

(3) The bounding box values xlo, xhi, ylo ... doesn't seems to give me the correct energy and structure
     as the simulation always result into loss of atoms or giving Nan energies. I already check the xyz file on VMD and xmakemol
      and all atoms have the correct bond length and angles. CrystalMaker shows all bonds are greater than 2.4 Angstroms. The box
       axes are orthogonal , but not cubic. Must the box be cubic?

(4) Are you doing any work on topotool for triclinic box with non-orthogonal axes?

Your help would be appreciated.

Suleiman.

LAMMPS data file. CGCMM style. generated by VMD/TopoTools v1.0 on Thu Mar 31 11:08:26 CDT 2011
676 atoms
0 bonds
0 angles
0 dihedrals
0 impropers
2 atom types
0 bond types
0 angle types
0 dihedral types
0 improper types
-22.964551 13.233451 xlo xhi
-21.790041 -9.475041 ylo yhi
-30.864607 -10.125607 zlo zhi

Masses

1 26.981539 # Al
2 63.546001 # Cu

Atoms

1 1 1 0.000000 -1.911010 -0.167990 -3.532720 # Al
2 2 1 0.000000 0.428050 -5.145990 -6.751170 # Al
3 3 1 0.000000 -1.332690 -10.253700 -10.130680 # Al
4 4 1 0.000000 1.006370 -15.231700 -13.349130 # Al
5 5 1 0.000000 -0.754370 -20.339411 -16.728649 # Al
6 6 1 0.000000 1.584690 -25.317400 -19.947100 # Al
7 7 1 0.000000 -0.176050 -30.425110 -23.326620 # Al
8 8 1 0.000000 -6.010810 -0.297700 -3.693790 # Al
9 9 1 0.000000 -3.671750 -5.275700 -6.912240 # Al
10 10 1 0.000000 -5.432490 -10.383410 -10.291760 # Al
11 11 1 0.000000 -3.093430 -15.361410 -13.510200 # Al
12 12 1 0.000000 -4.854170 -20.469120 -16.889721 # Al
13 13 1 0.000000 -2.515110 -25.447109 -20.108170 # Al
14 14 1 0.000000 -4.275860 -30.554819 -23.487690 # Al
15 15 1 0.000000 -10.110620 -0.427410 -3.854860 # Al
16 16 1 0.000000 -7.771550 -5.405410 -7.073310 # Al
17 17 1 0.000000 -9.532300 -10.513120 -10.452830 # Al
18 18 1 0.000000 -7.193240 -15.491120 -13.671280 # Al
19 19 1 0.000000 -8.953980 -20.598829 -17.050791 # Al
20 20 1 0.000000 -6.614920 -25.576820 -20.269239 # Al
**************** DATA TRUNCATED*************************

akohlmey · March 31, 2011, 7:33pm

Axel,

When creating xyz coordinate files from crystallographic data using multiple of lattice parameters (a, b,c) and alpha=beta=gamma = 90 topotool is quite useful for getting a LAMMPS input file, but I have been having problems with the bounding box values xlo, xhi, ylo, yhi , zlo and zhi.

I ran the following on VMD Tkconsole

% pbc set {12.2916 21.0939 29.9379 90.0 90.0 90.0}

% topo writelammpsdata input.coord full

I got the right input.coord file, but topotool listed the serial numbering twice (see data below)

no it is not. the first is the atom id, the second the molecule id.
since you have elected to write a data file in "full" style it has to be there.

I had to manipulate the file to remove unwanted columns before I could run LAMMPS. I was getting an error that reads

"Incorrect atom format in data file"

These are my questions;

(1) How can I exclude bonds, angles, dihedral and improper types when using the full command

"full" is the atom style and it has to match the atom style in your input.

(2) Why am I getting double serial numbering in the LAMMPS file which is the cause of the error.

you don't, see above. i cannot help much in case of PEBCAC.

How can I eliminate this without resorting to modifying the output file every time. Is it possible that
I am using an old version of topotool that comes with VMD?

the new VMD 1.9 has the up-to-date version of topotools. i _strongly_
advise to update VMD.
the new version has lots of bugfixes and useful new features.

(3) The bounding box values xlo, xhi, ylo ... doesn't seems to give me the correct energy and structure
as the simulation always result into loss of atoms or giving Nan energies. I already check the xyz file on VMD and xmakemol
and all atoms have the correct bond length and angles. CrystalMaker shows all bonds are greater than 2.4 Angstroms. The box
axes are orthogonal , but not cubic. Must the box be cubic?

no. you may have a buggy version of topotools. update to vmd 1.9, try again and
if the problem persists, send me some input to reproduce it.

(4) Are you doing any work on topotool for triclinic box with non-orthogonal axes?

reading is already supported for most cases. i am planning to add write support
(and expand the tutorials, and, and, and, ...), but i need time to do
this, and for
as long as i am not being paid out of some funding for that purpose, i have to
work on it in my extremely limited free time. most of the features that are
currently in topotools were implemented, because they are needed for local
research, or they are needed for something that i am interested in.
non-orthogonal
cell support is painful enough to get right on reading, but can be even
nastier on writing....

cheers,
axel.

_Oloriegbe_Suleiman · March 31, 2011, 8:14pm

Axel,

Yeah! Tell me about non-orthogonal box. They are nightmare to work with.
Our system admin is updating to VMD 1.9 as I write and hope that will resolve the problem.

One more quick question;

The topotool is assigning atom type 1 to Al and type 2 to Cu, While my setfl file require Al to be 2 and Cu to be 1.
What command do I need to issue to make topotool assign a particular atom type the correct ID?

Suleiman.

akohlmey · March 31, 2011, 8:20pm

Axel,

Yeah! Tell me about non-orthogonal box. They are nightmare to work with.
Our system admin is updating to VMD 1.9 as I write and hope that will resolve the problem.

One more quick question;

The topotool is assigning atom type 1 to Al and type 2 to Cu, While my setfl file require Al to be 2 and Cu to be 1.
What command do I need to issue to make topotool assign a particular atom type the correct ID?

try (in VMD console):

set t1 [atomselect top {name Al}]
set t2 [atomselect top {name Cu}]

$t1 set type 1
$t2 set type 2

and then write it out.

the code will sort entries by atom type and in ascii value
(so this trick will break down at 10 atom types), since that
is my personal preference how i like to generate data files
for coarse grain MD.

handling and preserving numerical atom types is on the
TODO list as well.

cheers,
axel.

Vamvakopoulos_Manoli · April 1, 2011, 4:00am

Dear all

Some of our users (Local Ioannina cluster) complain about corrupted trajectory
file or log file
(rj + fene bond potential + fix langevin and xyz ascii dump )

Actually with a unpredictable and random way appear in the dump ascii file or
lmp out file, series of @ character ( probably some birary data translate into
to this character ), with out failure of the parallel lmp run

This behavior took place in different version of lammps with different version
of mpich2

Do you have any idea in which direction we have to search ... for this behavior

Thanks you in advance

Best

E.V.

p.s.

Last version of lammps is compile which gcc version 4.1.2 20080704 (Red Hat
4.1.2-50) on SL 5 and linked with mpich2 ver. 1.1.1p1

akohlmey · April 1, 2011, 1:02pm

Dear all

Some of our users (Local Ioannina cluster) complain about corrupted trajectory
file or log file
(rj + fene bond potential + fix langevin and xyz ascii dump )

Actually with a unpredictable and random way appear in the dump ascii file or
lmp out file, series of @ character ( probably some birary data translate into
to this character ), with out failure of the parallel lmp run

This behavior took place in different version of lammps with different version
of mpich2

Do you have any idea in which direction we have to search ... for this behavior

yes.
a) check your file servers. you could have a broken disk in them.
b) check whether your users are running multiple jobs in the same
directory trying to update the same file. particularly NFS doesn't
respond well to this behavior.

it _definitely_ is not a lammps problem. if it was an issue with
the code, it would be more reproducible.

axel.

_Robert_Hoy · April 12, 2011, 12:44pm

Hey, guys. I see something similar with restart files, but only on Lustre file systems. They reproduce Vamakopoulos, does your cluster have a lustre file system? It turns out that corruption is a bad problem with these. The solution (afaict) seems to be “don’t use Lustre”. Not always possible

Rob

akohlmey · April 12, 2011, 1:27pm

rob,

Hey, guys. I see something similar with restart files, but only on Lustre
file systems. They reproduce Vamakopoulos, does your cluster have a lustre
file system? It turns out that corruption is a bad problem with these. The
solution (afaict) seems to be "don't use Lustre". Not always possible

lustre seems to be working pretty good in several places with
fairly large machines. there are some SNAFUs every once in
a while, but i suspect a lot of that depends on sticking to the
right version of kernel module and userland tools and how the
network is set up, e.g. how the load on the I/O servers is
distributed. to some degree, this can also be controlled from
the individual user that can change parameters on a per directory basis.

cheers,
axel.