A bug in -add-shells

[yfwang09]

Dear Pierre,

I recently found a bug in the -add-shells command (git version: commit 5ef1d7349e07c7aee43dd80d14eb5199fae49fa1). I was trying to add a shell model to a La2O3 crystal. Given the following input.lmp, the shell atoms cannot be correctly added:

 # LAMMPS input file for La2O3 unit cell

           5  atoms
           2  atom types

      0.000000000000       3.940000000000  xlo xhi
      0.000000000000       3.412140090911  ylo yhi
      0.000000000000       6.130000000000  zlo zhi
     -1.970000000000       0.000000000000       0.000000000000  xy xz yz

Masses

            1   138.90547000            # La
            2   15.99900000             # O

Atoms # atomic

         1    2       -0.000000000000       2.274760060607       3.966110000000
         2    1       -0.000000000000       2.274760060607       1.512271000000
         3    2        0.000000000000       0.000000000000       0.000000000000
         4    1        1.970000000000       1.137380030304       4.617729000000
         5    2        1.970000000000       1.137380030304       2.163890000000

Using the command atomsk input.lmp -add-shells all output.lmp, atomsk generates something like this:

 #           -

          10  atoms
           5  bonds
           4  atom types
           2  bond types

      0.000000000000       3.940000000000  xlo xhi
      0.000000000000       3.412140090911  ylo yhi
      0.000000000000       6.130000000000  zlo zhi
     -1.970000000000       0.000000000000       0.000000000000  xy xz yz

Masses

            1   51.30000000             # La core
            2   14.39910000             # O  core
            3   13.89054700             # La shell
            4   1.59990000              # O  shell

Atoms # full

         1           1    2   0.000000       -0.000000000000       2.274760060607       3.966110000000
         2           1    3   0.000000       -0.000000000000       2.274760060607       3.966110000000
         3           2    1   0.000000       -0.000000000000       2.274760060607       1.512271000000
         4           2    4   0.000000       -0.000000000000       2.274760060607       1.512271000000
         5           3    2   0.000000        0.000000000000       0.000000000000       0.000000000000
         6           3    3   0.000000        0.000000000000       0.000000000000       0.000000000000
         7           4    1   0.000000        1.970000000000       1.137380030304       4.617729000000
         8           4    4   0.000000        1.970000000000       1.137380030304       4.617729000000
         9           5    2   0.000000        1.970000000000       1.137380030304       2.163890000000
        10           5    3   0.000000        1.970000000000       1.137380030304       2.163890000000

Bonds

           1           1           1           2
           2           2           3           4
           3           1           5           6
           4           2           7           8
           5           1           9          10

where the shell atoms (type 3 and 4) are incorrectly assigned. I have tried several things to fix this issue, and I find that the problem only shows up when the first atom (atom id = 1) has the atom type 2. i.e. If I swap the first two atoms (id=1 and id=2) in the input.lmp:

...
Atoms # atomic

         1    1       -0.000000000000       2.274760060607       1.512271000000
         2    2       -0.000000000000       2.274760060607       3.966110000000
         3    2        0.000000000000       0.000000000000       0.000000000000
...

Using the same command, atomsk is able to generate the correct core-shell structure.

It would be great if this bug could be fixed in the coming iteration.

Thank you, Yifan

[pierrehirel]

Dear Sir,

Thank you for your message.

Indeed when writing a LAMMPS data file, Atomsk generates new "types" for the shells. If the atom "types" are already defined but not in increasing order, it leads to this bug. I will try to modify the code to fix this bug.

With that said, I always advise against using LAMMPS data format for intermediate files when constructing an atomic system. This file format only stores atom "types" and not necessarily chemical species, which messes things up. Use another file format (like CFG) for intermediate files, and you will have fewer problems. Use the LAMMPS data format only when writing your final output file.

I'll come back here when I solve the problem.

Best regards

[pierrehirel]

I just pushed a new version of the code. You may download it from GitHub to test it. I would appreciate if you could confirm that it solves your problem.

Best regards

[yfwang09]

Thank you for your prompt reply! The problem has been fixed in the new version.

Regarding using other types as intermediate files, I actually tried to use .gin file as the intermediate (since .cfg does not supply the core-shell model). However, since gin does not specify the type number (only by element name), when I convert .gin file to .lmp file, the order of O and La are always reversed because the first atom in the file is O. For the example I provided earlier,

atomsk input.lmp -add-shells all output.gin
atomsk output.gin lmp

This leads to O and La with the type numbers (1,3) and (2,4), respectively. Although it is not the result I expected, I am not sure whether this should be considered a bug. Just listed here for your reference.

Thank you for your quick reply and prompt fix!

[pierrehirel]

I apologize for the delayed answer, but I understand this issue is fixed now so I will close it.

Concerning your last remark, it is not a bug. When atom "types" are not defined, Atomsk generates new types in order of appearance of the atoms. If O atoms appear first then they are assigned type 1, and so on. To fix this, just change the order of atoms, or write atom types in a file and use option "-properties" to assign types.