Polycrystal is sometimes missing planes of atoms about atomsk HOT 4 CLOSED

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

from atomsk.

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?

from atomsk.

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":

4f8e2a0#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...

from atomsk.

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

from atomsk.