Polycrystal is sometimes missing planes of atoms

[jfikar]

Dear Pierre,

I'm creating an aluminium polycrystal with just four hexagonal grains of the same orientation and for some sample sizes the result is missing a plane of atoms on the top and on the bottom (Z-direction).

With the up-to-date atomsk, you can reproduce the problem with:

poly.txt:

box 700 606.21785 100
node .25000000000000000000*box 0*box .50000000000000000000*box 0 0 -32.80517578125000000000
node .75000000000000000000*box 0*box .50000000000000000000*box 0 0 -19.13818359375000000000
node .50000000000000000000*box .50000000000000000000*box .50000000000000000000*box 0 0 96.65771484375000000000
node 0*box .50000000000000000000*box .50000000000000000000*box 0 0 -119.65209960937500000000

script.sh:

rm poly.cfg Al.xsf poly.lmp poly_nodes.xsf poly_grains-com.xsf poly_id-size.txt poly_size-dist.txt
atomsk --create fcc 4.04999918095267 Al orient [1-10] [001] [110] xsf -v 0
atomsk --polycrystal Al.xsf poly.txt poly.cfg -wrap -v 0
atomsk poly.cfg poly.lmp -v 0

The resulting file poly.cfg or poly.lmp does not have periodicity in the Z-direction (where the 4 grains are supposed to be infinite) and contains 2,524,654 atoms.

When I'm using older atomsk (Feb 2022), there is periodicity in Z-direction and sample contains 2,561,160 atoms.

When inspecting the lmp file, I see that the wrong file has atoms between z=1.2295-98.5981 A, while the correct file has them between z=0.9845-99.7850 A. There is a plane of atoms missing on the bottom and on the top of the wrong sample.

Actually, I first discovered the bad behavior with slightly larger box and the old atomsk (Feb 2022). This one fails with the old atomsk, but it is correct with the up-to-date one.

poly.txt:

box 800 692.8204 100
node .25000000000000000000*box 0*box .50000000000000000000*box 0 0 77.76123046875000000000
node .75000000000000000000*box 0*box .50000000000000000000*box 0 0 129.11132812500000000000
node .50000000000000000000*box .50000000000000000000*box .50000000000000000000*box 0 0 82.80395507812500000000
node 0*box .50000000000000000000*box .50000000000000000000*box 0 0 83.37524414062500000000

Old atomsk: 3,297,130 atoms, broken periodicity in Z. New atomsk: 3,345,265 atoms, periodicity in Z OK.

So my thought were: oh, it was fixed in the new code. But actually it fails now for a slightly different size.

EDIT: There is one more sample size, which now with up-to-data atomsk produces wrong sample and with the old one (Feb 2022) was fine:

poly.txt:

box 200 173.2051 100
node .25000000000000000000*box 0*box .50000000000000000000*box 0 0 -32.80517578125000000000
node .75000000000000000000*box 0*box .50000000000000000000*box 0 0 -19.13818359375000000000
node .50000000000000000000*box .50000000000000000000*box .50000000000000000000*box 0 0 96.65771484375000000000
node 0*box .50000000000000000000*box .50000000000000000000*box 0 0 -119.65209960937500000000

[pierrehirel]

Dear Jan,

My apologies for the late reply, I was caught up in different things and did not have time to look into this earlier.

Although you say this problem did not exist before and arised in recent versions (from the master branch I presume), I will make some comments on the data that you describe:

(1) According to your first command, the unit cell has a [110] crystal axis along Z, i.e. a length of 2.86378188 Å. Then, you set the final box size to 100 along Z, which is not a multiple of the unit cell length. So, it is not surprising that the final system is not periodic along Z. Why you obtain a "periodic" crystal with older versions of Atomsk, I do not understand, maybe the planes happen to be aligned just by chance.

(2) When constructing 2-D polycrystals, my advice is to set the box length to zero along the "short" axis (here Z in your case), for two reasons: (a) it ensures that the generated polycrystal is periodic; (b) it is computationally more efficient, because Atomsk only has small volumes to fill with atoms. Then, to generate a columnar system, you may duplicate the system afterwards.

I tried it with the following data:

box 350 303.11 0
node .25000000000000000000*box 0*box .50000000000000000000*box 0 0 -32.80517578125000000000
node .75000000000000000000*box 0*box .50000000000000000000*box 0 0 -19.13818359375000000000
node .50000000000000000000*box .50000000000000000000*box .50000000000000000000*box 0 0 96.65771484375000000000
node 0*box .50000000000000000000*box .50000000000000000000*box 0 0 -119.65209960937500000000

And then the following command:

atomsk --polycrystal Al.xsf poly.txt poly.cfg -wrap -dup 1 1 10

The final system is periodic.

I hope this allows you to construct systems relevant for your studies.

Best,

Pierre

[jfikar]

Dear Pierre,

thank you for you explanation. Your steps indeed do fix the problem of the periodic boundary in Z.

However, there is still a small discrepancy in number of atoms and also in the atomic positions if I reproduce exactly your example (first 0 thickness in Z and the 10x duplicate) with the new atomsk (master branch) and the old atomsk (master branch around Feb 2022).

The new atomsk gives 182860, while the old one 182900, so 40 atoms more. Both of the samples in ovito look to have periodicity in Z direction. Anyway, 40 atoms are difficult to spot. But it seems the Z coordinate in the old polycrystal has some slightly shifted values. The X and Y are not exactly the same either. Maybe it is kind of rounding error? Or some other error, which got fixed meanwhile in poly?

[pierrehirel]

Indeed some bugs had to be fixed since latest release, which can change the number of atoms when constructing polycrystals.

In particular, there was a bug in converting Euler angles into rotation matrix, see Commit f19cdf1.

There was also a bug when the number of nodes was very small, which lead to modifying a large portion of the code of mode "--polycrystal":

https://github.com/pierrehirel/atomsk/commit/4f8e2a03230ee162ebdac2f77f8df3cb18067405#diff-fcc64fc3a40b149f0effc02693d58f7cc7d35fba628d3cb483ea7e6cb6df83c7

Anyway, this mode is extremely difficult to debug, because each and every user has so different needs. I know it works pretty well when the box is roughly cubic, but becomes more touchy when the box is a very elongated rectangle, or when nodes have a very non-uniform distribution, and so on. I try to keep up with the bugs reported to me, hoping that solving one bug will not open dozens more...

[jfikar]

I see, both changes are between the old and new atomsk. I agree, it is difficult to debug. From my point of view, both the new and old polycrystals are valid using your method and it explains the difficulties I had encountered.

Thank you