About the *.sw file, formatting the file and error message

LAMMPS LAMMPS Mailing List Mirror
1

Dear all,

I wish to use a SW potential for a simulation involving a Mg-Al-Si-O system. For this I have created a *.sw file with 64 permutations of the previously mentioned atoms (below the 64 permutations are listed). I have a couple of questions that arose from trying to use my *.sw file in lammps: I get the following error message:

“Reading potential file MgAlSiO.sw with DATE: 01.10.2018
ERROR: Potential file is missing an entry (…/pair_sw.cpp:501)
Last command: pair_coeff * * MgAlSiO.sw Mg Al Al Si Si Si O O O O O O”

Now each line of parameters contains 11 numerical parameters (as required according to the description of the pair_style sw), along with the three atom names. So I assume this error does not come from there. I suppose it comes from the number of permutations required to exist in the *.sw file. Now I wonder:

  1. How does lammps know the number of permutations that must exist in the *.sw file? In my model I wish to use 12 different atom types; but only four different elements (namely Mg, Al, Si, and O). Is it due to the number of different elements named in the command: “pair_coeff * * MgAlSiO.sw Mg Al Al Si Si Si O O O O O O”? If that is the case: why 64 permutations would not be the necessary number of entries?

  2. Is there any special rule that applies to the formatting of the *.sw file? I use single space to separate all the different values in each line. For example: “O Al Al 1.0 1.0 2.6 6.2400 2.0 -0.333313 0.0 0.0 0.0 0.0 0.0”. Could the error come from this? If it does, what would be a good way to format the *.sw file?

Thanks a lot for your help.

Sincerely,

2

Dear all,
I wish to use a SW potential for a simulation involving a Mg-Al-Si-O
system. For this I have created a *.sw file with 64 permutations of the
previously mentioned atoms (below the 64 permutations are listed). I have a
couple of questions that arose from trying to use my *.sw file in lammps: I
get the following error message:

"Reading potential file MgAlSiO.sw with DATE: 01.10.2018
ERROR: Potential file is missing an entry (../pair_sw.cpp:501)
Last command: pair_coeff * * MgAlSiO.sw Mg Al Al Si Si Si O O O O O O"

Now each line of parameters contains 11 numerical parameters (as required
according to the description of the pair_style sw), along with the three
atom names. So I assume this error does not come from there. I suppose it
comes from the number of permutations required to exist in the *.sw file.
Now I wonder:

1. How does lammps know the number of permutations that must exist in the
*.sw file? In my model I wish to use 12 different atom types; but only four
different elements (namely Mg, Al, Si, and O). Is it due to the number of
different elements named in the command: "pair_coeff * * MgAlSiO.sw Mg Al
Al Si Si Si O O O O O O"? If that is the case: why 64 permutations would
not be the necessary number of entries?

​they are. i just took your list of permutations from below and added for
each of them 11 numbers taken from Si.sw. when i add pair_style sw and your
pair_coeff command, it works on my machine.​

2. Is there any special rule that applies to the formatting of the *.sw
file? I use single space to separate all the different values in each line.
For example: "O Al Al 1.0 1.0 2.6 6.2400 2.0 -0.333313 0.0 0.0 0.0 0.0
0.0". Could the error come from this? If it does, what would be a good way
to format the *.sw file?

​the par​ser reads "words" separated by whitespace (i.e. blank, tab,
line-feed, carriage-return, form-feed) until it has enough. they can be
distributed over multiple lines. in my test case, i put the entire entries
for a single tuple of elements on the same line. but i can insert newlines
arbitrarily and have no problems.

the most likely issue is, that you may be missing a number somewhere, or
missing a blank, or are using a non-ASCII whitespace character (which
LAMMPS does not recognize as such).

axel.

3

Thank you, Axel.

I reworked all the “space” characters in my *.sw file and it worked as intended. It must have been a non-ASCII whitespace character, as you pointed out.