Save redundancy in the input file

Hi all,

I’m just starting to use lammps to do a damped MD simulation to find the energy minimum for a large 2d layer with about 1k atoms. The system is a big triangular superlattice and is not periodic. I see that in order to name all the interactions in the system there is a lot of redundancy in the input file.

For example, I have to specify the interaction between the 1st atom and each of the other atoms, though there may be no interaction between 1st and 1000 th atom at all, I still have to put many zeros in the input file. This causes a ~10GB input file.

I was wondering how I can cut this redundancy and only specify the interaction that is meaningful in the input file.

Thanks,
Lijie

Hi all,

I'm just starting to use lammps to do a damped MD simulation to find the
energy minimum for a large 2d layer with about 1k atoms. The system is a big
triangular superlattice and is not periodic. I see that in order to name all
the interactions in the system there is a lot of redundancy in the input
file.

For example, I have to specify the interaction between the 1st atom and each
of the other atoms, though there may be no interaction between 1st and 1000
th atom at all, I still have to put many zeros in the input file. This
causes a ~10GB input file.

I was wondering how I can cut this redundancy and only specify the
interaction that is meaningful in the input file.

you don't explain, why you have to specify all interactions
explicitly, i.e. give each atom a different type.
in a typical simple input all atoms would have the same atom type and
then only one set of parameters needs to be specified.
more complex systems have a few atom types, even for complex
biomolecular systems, there are rarely more than 50 atom types,
and there all mixed terms can be inferred from the interactions of
those 20-50 atom types with itself through applying a mixing rule.

axel.

The superlattice (~1k atoms) we model is not periodic and each atom has a uniquely different environment so we have to give a different type to each atom.

For a similar but much smaller system(~12 atom types), we can build a reasonable potential file. The only obstacle of scaling this file to ~1k atoms is that we need to specify all unnecessary zeros in the end of the file that look like:

zero terms

Se1 Se1 Se1 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000 4 0 0.000
Se1 Se1 W1 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000 4 0 0.000
Se1 Se1 Se2 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000 4 0 0.000
Se1 Se1 Se3 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000 4 0 0.000
Se1 Se1 W2 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000 4 0 0.000

Is there any way getting around adding zero terms? or do we have to hack the source code?

I have attached the potential file, input file in this email.

They come from this paper: https://arxiv.org/abs/1704.03147

Also the input files can be downloaded at: http://jiangjinwu.org/sw

Thanks,
Lijie

h-wse2.sw (154 KB)

in.tension (2.63 KB)

lammps.dat (3.11 KB)

The superlattice (~1k atoms) we model is not periodic and each atom has a
uniquely different environment so we have to give a different type to each
atom.

no, you don't. how many atom types you have to define depends solely
on the force field, not on your geometry or whether it has periodic
boundaries or not.
and from what i understand, there are only 12 distinct atom types for
the force field you are using.

actually, two would be sufficient, if it wasn't for the fact, that the
force field you want to use does not 100% comply with the regular
stillinger-weber formalism.
the normal SW setup consists of a pair wise additive term that is
element specific and an angle dependent term with a fixed equilibrium
angle and which depends in essence only on the central atom type. i.e.
you can have a parameterization for diamond or graphite, but not one
for both.

the force field that you want to use, however, allows for multiple
equilibrium angle values and works around the limitation of the SW
formalism by defining multiple atom types to differentiate between
those.

For a similar but much smaller system(~12 atom types), we can build a
reasonable potential file. The only obstacle of scaling this file to ~1k
atoms is that we need to specify all unnecessary zeros in the end of the
file that look like:

# zero terms
Se1 Se1 Se1 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000
4 0 0.000
Se1 Se1 W1 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000
4 0 0.000
Se1 Se1 Se2 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000
4 0 0.000
Se1 Se1 Se3 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000
4 0 0.000
Se1 Se1 W2 0.000 1.000 1.000 1.000 1.000 1.000 1.000 1.000
4 0 0.000
......

Is there any way getting around adding zero terms? or do we have to hack the
source code?

i think that your problem is in the defining of the geometry and how
you assign atom types.
it is highly unlikely that you need more atom types. i think you are
misinterpreting what is an atom type.

since LAMMPS is open source, you are also free to modify it to serve
your needs better. in any case, you have not so far produced a
*convincing* proof, that there is something wrong with LAMMPS, or that
something needs to be improved on the LAMMPS side. unless you do, i
will assume, that this is something that needs to be addressed on your
side.

axel.