Hello,
I'm trying to produce BCC polycrystals with 12 randomly oriented grains largely elongated in Z direction (at least 1:10 or higher ratio).

In this case "random 12" does not seem to work, as it somehow tends to produce almost equiaxed grains. I have tried 12 prismatic grains with hexagonal base. First approximately equiaxed:

poly.txt:

box 134.7 116.6 50
node 0.125box 0.0000box 0.5box random
node 0.125box 0.3333box 0.5box random
node 0.125box 0.6667box 0.5*box random

node 0.375box 0.1667box 0.5box random
node 0.375box 0.5000box 0.5box random
node 0.375box 0.8333box 0.5*box random

node 0.625box 0.0000box 0.5box random
node 0.625box 0.3333box 0.5box random
node 0.625box 0.6667box 0.5*box random

node 0.875box 0.1667box 0.5box random
node 0.875box 0.5000box 0.5box random
node 0.875box 0.8333box 0.5*box random

Then I run:

atomsk --create bcc 3.1652 W xsf
atomsk --polycrystal W.xsf poly.txt poly.lmp -wrap

Then the I open the resulting file in Ovito and run Structure Identification > Common Neighbor Analysis (you can use Ackland-Jones or VoroTop, results are the same), it finds approximately 70% BCC atoms. This seems reasonable.

Then I stretch the box 10 times in Z:
box 134.7 116.6 500

and in this case Ovito finds only about 30% BCC atoms. The non-BCC are on top and down on each hexagonal column. I understand there is a problem on the PBC in Z direction, but I somehow thought, there will be just a small number of disordered atoms, not the majority of them.

In atomsk manual there is also 2D polycrystal produced by specifying 0 in Z direction:
box 134.7 116.6 0

That works well, about 75% of BCC atoms, but I have all the grains oriented <100> in the Z direction.

Is there any other way to produce randomly oriented elongated grains?

Dear Pierre,

I recently found a bug in the -add-shells command (git version: commit 5ef1d73). 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

Dear Pierre,

First thank you for making this fantastic software that helps me a lot in my work.

I would like to report a bug regarding adding atoms to an existing LAMMPS file.

Step to recreate

1. atomsk --create bcc 2.856 Fe orient [100] [010] [001] -duplicate 2 2 2 lammps
2. atomsk Fe.lmp -add-atom H random 111 lammps
3. Give the new file a name and check the created LAMMPS file

Potential bug

Suggested change

Change the line whenever new atom type is added when modifying a LAMMPS file.

Merry Christmas and happy new year!

Best regards,
QLRO

Dear Pierre,
Thanks for your efforts in developing Atomsk.
Recently, I have trouble creating a complex dislocation loop. When I tried to use -disloc file option, it seems to not work as I hoped. As shown in the attached screenshot, the program can't recognize the third parameter -- Poisson ratio.
Looking forward to your reply!

Best regards

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

Great application. I only hope that *.stru file type would be supported in the future.

Many thanks.

Example of a stru file is:

title 3D
spcgr P-3m1
cell 3.26109, 3.26109, 4.64484, 90.00000, 90.00000, 120.00000
atoms
H 0.33333299, 0.66666698, 0.41054699, 0.39478418, 1
H 0.66666698, 0.33333299, 0.57501602, 0.39478418, 1
Ni 0.00000000, 0.00000000, 0.00000000, 1.21704066, 1
O 0.33333299, 0.66666698, 0.22034200, 2.53759384, 1
O 0.66666698, 0.33333299, 0.77965802, 2.53759384, 1

Dear Pierre,

I think I found another problem in polycrystal. This time I was creating equilateral randomly oriented grains of tungsten and I was looking at its elastic properties.

box 50 50 50
random 12

I did 1000 of such samples and the Young modulus in Z is on average for some reason smaller than in X and Y. I could also get the standard deviation and the difference of Young modulus in Z and X or Y is 20x the standard deviation. So probably it is not a random effect.

Moreover, tungsten has quite isotropic elastic constants. I think the effect would be grater for anisotropic material.

As a test I created one big sample, equal to my 1000 smaller samples

box 500 500 500
random 12000

And I inspected the angles written in poly_param.txt, the first and third angle are uniformly distributed -180..180deg and the second 0..180deg with maximum in 90deg.

I think I found the place related to this problem in mode_polycrystal.f90, it is around line 775 you have a comment:

!NOTE: just multiplying the three random numbers by 2pi results in a biased distribution
!See J.J. Kuffner, Proc. 2004 IEEE Int'l Conf. on Robotics and Automation (ICRA 2004)
       !or http://mathworld.wolfram.com/SpherePointPicking.html

This is true, but it seems, you are mixing the first method (eq. 1 and 2 referenced by Wolfram), where just two angles are generated to cover the sphere (latitude ϕ and longitude θ) with a third independent rotation. I'm not sure it is correct.

I did check the rotation matrices (similar to the ones you have in the code) for the angles from poly_param.txt and plotted the position of X-axis (1 0 0) after the 12000 random rotations and I get only half of the sphere covered with a lot of points around the pole and not so much at the equator.

I think this is the reason of the observed anisotropy of the generated polycrystals. I think the proper random rotation is in fact more complex. Probably the best is the approach of Arvo. You'll get directly the rotation matrix. I'm however not sure, how to get the two angles back. One angle is obvious.

Hi,

I am wondering how to select atoms randomly but that match a certain criteria. For instance, suppose I have a supercell and I want to select say 18 random atoms but only within the upper half of the box.

When I use the "-select in box" option paired with the "-select intersect random 18 any", first the upper half is selected but the selection is replaced with 10 random atoms within the entire supercell. Maybe the syntax is incorrect. I used

atomsk initial.xyz -select in box 0 198 0 INF 372 INF -select intersect random 18 Fe -rmatom select final.xyz

I get the following messages

..> Input file was read successfully (365184 atoms).

Selecting atoms inside the box.
..> Box bounds: (0.000,198.000,0.000); (+INF,372.000,+INF).
..> 156950 atoms are now selected.
Selecting randomly 18 atoms of Fe.
..> 156942 atoms were removed from the selection.
..> 8 atoms are now selected.
Removing all selected atoms from the system.
..> 8 atoms were removed, 365176 atoms left.
Selected atoms were removed: the selection previously defined was cleared.
Writing output file(s) (365176 atoms):

Dear Sir/Madam,

Latest update on Atomsk is so useful but I encountered a situation with polycrystal command and related commands (similar to https://atomsk.univ-lille.fr/tutorial_polycrystal.php) while creating a polycrystal configuration. The final wrapped configuration is having cavities/unfilled spaces. It seems the voronoi cells are not getting completed or touching each other. Earlier versions of Atomsk was working fine in this issue.

Thank you

Hello,
I would like to convert quantum espresso output (geometry optimization) to a series of cif files. I tried to use atomsk, but coordinates and cell parameters/vectors in the output are wrong. I tried the following lines:
atomsk --one-in-all geo_opt.txt cif
atomsk --one-in-all geo_opt.txt cif -u angstrom angstrom
atomsk --one-in-all geo_opt.txt cif -u angstrom angstrom -rebox

I opened quantum espresso output file using xcrysden and everything looks ok there. Quantum espresso output: geo_opt.txt

Dear Pierre,

I think I found another small bug in the latest polycrystal code. When I'm creating randomly oriented grains with prescribed positions of nodes, it seems just one random orientation is used for all the grains. It was probably introduced with latest rotation matrices, as before the orientations were not the same.

atomsk --create bcc 3.1652 W xsf
atomsk --polycrystal W.xsf poly.txt poly.cfg

poly.txt:

box 106.6 79.9 40
node 0.125*box 0.0000*box 0.5*box random
node 0.125*box 0.3333*box 0.5*box random
node 0.125*box 0.6667*box 0.5*box random
node 0.375*box 0.1667*box 0.5*box random
node 0.375*box 0.5000*box 0.5*box random
node 0.375*box 0.8333*box 0.5*box random
node 0.625*box 0.0000*box 0.5*box random
node 0.625*box 0.3333*box 0.5*box random
node 0.625*box 0.6667*box 0.5*box random
node 0.875*box 0.1667*box 0.5*box random
node 0.875*box 0.5000*box 0.5*box random
node 0.875*box 0.8333*box 0.5*box random

and then poly_param.txt gives:

# Random positions and rotations of grains generated by Atomsk
# This parameter file can be used to generate the same polycrystal
box       106.600000       79.900000       40.000000
node        13.325000        0.000000       20.000000       24.494790      -20.348470      162.461182
node        13.325000       26.630670       20.000000       24.494790      -20.348470      162.461182
node        13.325000       53.269330       20.000000       24.494790      -20.348470      162.461182
node        39.975000       13.319330       20.000000       24.494790      -20.348470      162.461182
node        39.975000       39.950000       20.000000       24.494790      -20.348470      162.461182
node        39.975000       66.580670       20.000000       24.494790      -20.348470      162.461182
node        66.625000        0.000000       20.000000       24.494790      -20.348470      162.461182
node        66.625000       26.630670       20.000000       24.494790      -20.348470      162.461182
node        66.625000       53.269330       20.000000       24.494790      -20.348470      162.461182
node        93.275000       13.319330       20.000000       24.494790      -20.348470      162.461182
node        93.275000       39.950000       20.000000       24.494790      -20.348470      162.461182
node        93.275000       66.580670       20.000000       24.494790      -20.348470      162.461182

I've also inspected the sample visually and it indeed looks like all the grains have the same orientation.

Dear Pierre,

I found another thing, which makes reproducibility of my polycrystalline calculations more difficult. When I create a polycrystal twice from the same file, the result is identical, but the order of atoms in the file is somehow random. This in general shouldn't be a problem, but in my LAMMPS elastic calculation there is:

displace_atoms all random ${atomjiggle} ${atomjiggle} ${atomjiggle} ${seed} units box

which displaces the atoms by small amount and if the seed number is the same, the calculation should be completely reproducible. But in fact it is not, as the atom order changes.

I think it is due to OMP. For now I use as a workaround OMP_NUM_THREADS=1, but then the calculations are slower.

Is there another way to keep the order of atoms deterministic? I thought about sorting the atom at the end like -sort x, but it may not always work, as there can be multiple atoms with the same x.

Building the latest release causes a compilation error due to a missing file:

gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/mode_merge.o  -c mode_merge.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/1ia_dlpoly_history.o  -c 1ia_dlpoly_history.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/1ia_qe_out.o  -c 1ia_qe_out.f90
make[1]: *** No rule to make target `1ia_vasp_outcar.o', needed by `modes'.  Stop.

I checked out the previous commit and compiled with no issues so it seems to be an issue with the latest change.

It seemed that the auxiliary properties did not work when I tried to visualize a constructed polycrystal in OVITO with color coding according to grain ID. All atoms in the simulation cell belong to one grain ID. I examined the CFG file. Only one line is found with the keyword "grainID": "auxiliary[0] = grainID", and the other lines are atomic positions. It seems that auxiliary[] is a list and there should be lines with auxiliary[1], auxiliary[2]..., I am not sure and do not know where they should be.

There is an issue while generating a lattice with both -rotate and -orthogonal-cell options. Consider the following:

I execute atomsk for 100 times and grepping the number of atoms

for i in `seq 1 100` 
do 
./atomsk --create fcc 1.386720 Al -rotate Z 45 -orthogonal-cell -ow 25_lat.xsf | grep "Writing"
done

Here's the output I get which varies from 5 to 8 randomly. Am I missing something here?

 >>> Writing output file(s) (6 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (5 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (6 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (6 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (6 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (6 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (6 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (8 atoms):
 >>> Writing output file(s) (7 atoms):

Hi,

I'm trying to generate dozens of the binary alloys with the same composition by a shell script like this:

`
#!/bin/bash
export PATH=$PATH:~/atomsk_b0.12.1_Linux-amd64

lattice=3.165
element1='W'
element2='V'
ratio='5%'
structure_size_x=20
structure_size_y=20
structure_size_z=20
structure_file_name='data.lmp'

for i in seq 1 1 20
do
mkdir $i
cd $i
atomsk --create bcc $lattice $element1 -duplicate $structure_size_x $structure_size_y $structure_size_z -select random $ratio $element1 -substitute $element1 $element2 $structure_file_name
cd ..
done
`

The output structure should be WV alloy with 5% V content. But sometime the output structure become WV alloy with 5% W content.

This situation occurred approximately 1 to 2 times in 20 iterations.

I'm not sure what's going here.

Thanks for your help!

Best regards,
Cui

Hi,

I'm currently using python as a wrapper (using subprocess) around atomsk for generating polycrystals. I need specific stoichiometry for charge balancing so I am just run it repeatedly until I happen to hit one which works. The issue is that this means there is a ton of fileIO each iteration (load in the primitive cell, write the polycrystal to disk, then load it back in to python to check the stoichiometry.

Having the output go to stdout rather than to disk would massively increase the speed of this operation.

I am new to Atomsk and would appreciate guidance on utilizing Atomsk to transform a lattice matrix using a specified transformation matrix. Allow me to provide additional details regarding my query.

I have an exemplary structure represented in the VASP POSCAR file format, denoted as POSCAR_120.vasp. My objective is to apply the transformation matrix M to this structure and generate a modified version, saved as POSCAR_60.vasp.

$ cat POSCAR_120.vasp 
CrSTe
   1.0000000000000000
     3.4619999999999997    0.0000000000000000    0.0000000000000000
    -1.7309999999999992    2.9981799479017264    0.0000000000000000
     0.0000000000000000    0.0000000000000000   20.0000000000000000
   Cr   S    Te
     1     1     1
Selective dynamics
Direct
  0.0000000000000000  0.0000000000000000  0.5000000000000000   F   F   F
  0.3333333333333357  0.6666666666666643  0.5607565969958570   F   F   T
  0.6666666666666643  0.3333333333333357  0.3988907086676957   F   F   T

$ cat POSCAR_60.vasp 
CrSTe
   1.0000000000000000
     3.4619999999999997    0.0000000000000000    0.0000000000000000
     1.7310000000000005    2.9981799479017264    0.0000000000000000
     0.0000000000000000    0.0000000000000000   20.0000000000000000
   Cr   S    Te
     1     1     1
Selective dynamics
Direct
  0.0000000000000000  0.0000000000000000  0.5000000000000000   F   F   F
  0.6666666666666714  0.6666666666666643  0.5607565969958570   F   F   T
  0.3333333333333286  0.3333333333333357  0.3988907086676957   F   F   T

The transformation matrix M is

$ cat TRANSMAT 
Read transformation matrix from the TRANSMAT.in file if it exists. 
    1    0    0          # must be three integers
    1    1    0          # must be three integers
    0    0    1          # must be three integers

While reading an input file (tested for *lmp), atomsk cannot read atoms with index that are "out of bounds".

/!\ WARNING: atom index #******* is out of bounds, skipping.

This could be however useful when, for example, atoms have been removed manually or by a third party software, leaving then atoms index higher than the total count of atoms.

I don't have the time right now to look into the code, but I could do it in some weeks :)

For lammps file generation, the lmp output file do not have pair coefficients.

Output file:
LAMMPS (7 Aug 2019)
units real
dimension 3
atom_style charge
boundary p p p

pair_style lj/cut 12.0
#bond_style harmonic
#angle_style cosine/periodic
#dihedral_style harmonic
pair_modify tail yes mix arithmetic
#special_bonds lj/coul 0.0 0.0 1.0

read_data 1525727.lmp
orthogonal box = (0 0 0) to (32.49 32.49 25.78)
1 by 1 by 1 MPI processor grid
reading atoms ...
1500 atoms
read_data CPU = 0.00899792 secs
variable dt equal 1.00
variable tdamp equal 100*${dt}
variable tdamp equal 100*1
fix 1 all langevin 298.00 298.00 ${tdamp} 2907865
fix 1 all langevin 298.00 298.00 100 2907865
fix 2 all nve
thermo 0
run 1000
ERROR: All pair coeffs are not set (../pair.cpp:230)
Last command: run 1000

Dear Pierre,

I think I've found another bug in atomsk. I'm creating my hexagonal tungsten polycrystal as before, just this time the box is smaller in Z:

atomsk --create bcc 3.1652 W xsf
atomsk --polycrystal W.xsf poly.txt poly.cfg

poly.txt:

box 106.6 79.9 40
node 0.125*box 0.0000*box 0.5*box random
node 0.125*box 0.3333*box 0.5*box random
node 0.125*box 0.6667*box 0.5*box random
node 0.375*box 0.1667*box 0.5*box random
node 0.375*box 0.5000*box 0.5*box random
node 0.375*box 0.8333*box 0.5*box random
node 0.625*box 0.0000*box 0.5*box random
node 0.625*box 0.3333*box 0.5*box random
node 0.625*box 0.6667*box 0.5*box random
node 0.875*box 0.1667*box 0.5*box random
node 0.875*box 0.5000*box 0.5*box random
node 0.875*box 0.8333*box 0.5*box random

Then the grain number one is no more hexagonal, but it is on one side bigger bordered with right angle. It also contains more atoms than the other grains, as it is outputted by atomsk: about 2600 atoms, while other grains have around 1800 atoms. Then the extra atoms from grain one are inside of other grains via periodic boundary conditions. Here I omitted the -wrap switch so the wrong shape of the grain number one is obvious.

The weird shape of grain number one happens when the box Z dimension is 0 - 40 A. At 45 A and bigger it behaves as expected.

It seems the order of nodes is not the problem, it seems it is the position of node one.

Dear Pierre,

First of all, thanks for creating this software which helps me a lot. When I wanted to create a larger polycrystal, the error appeared:X!X ERROR: memory (RAM) is insufficient to perform this operation. I already know that it is related to the ALLOCATE in Fortran. But, my computer has 16 GB of RAM, more than the error shows. Is there any method to solve this problem or I should change to a better computer?

Looking forward to your reply.
Yours sincerely.
Siyao

Dear Pierre,
Thanks for great software,
I installed the atomsk in mac OS,
it installed but showing error when we use the atomsk
dyld: Library not loaded: /usr/local/gfortran/lib/libquadmath.0.dylib
Kindly let me know the solution

Best
Nilesh

By using the cell of cell of non-identical displacement (CNID) technique, we can construct more reasonable and fewer interface models, thus greatly reducing the work of subsequent calculations. See here for more detailed explanations on cell of non-identical displacement (CNID).

I want to know if atomsk supports this feature, aka, constructing different stack models for an interface by sampling cell of non-identical displacement (CNID), as done in interface_master?

Regards,
Zhao

Master branch, Mac Sierra 10.12.6

When creating a grain boundary using the fluorite crystal structure, occasionally atoms will not be written, creating unexpected vacancies. This only seems to occur when reading the seed file from a separate directory other than the current one.

Given a file structure as follows:
$HOME/atomsk/unit_cells/uo2_seed.lmp
$HOME/atomsk/gbs/gb.txt

where uo2_seed.lmp is the file created by the command atomsk --create fluorite 5.453 U O lammps and gb.txt contains the following lines

box 60.9663934 60.9663934 5.453
node 0.5*box 0.25*box 0 0° 0° -26.56°
node 0.5*box 0.75*box 0 0° 0° 26.56°

then running the following command in $HOME/atomsk/gbs/gb.txt:
for i in $(seq 1 10); do atomsk --polycrystal ../unit_cells/uo2_seed.lmp gb.txt uo2_gb_${i}.lmp; done
creates several uo2_gb files which can show different U or O vacancies (images attached)
uo2_gbs.tar.gz

If the seed file is copied to the same directory, and the same for command run, nearly all the files contain all atoms (I had run this several times without any apparent vacancies, but on the last test on U atom was missing - images attached uo2_gbs_same_dir.tar.gz)

I have also attached the associated .lmp files

lmp_files.tar.gz

Hi Pierre,

I'm trying to construct a polycrystal with random rotation angles X, Y, Z, which are generated by a bash script using bc -l. The file looks for example like this:

box 400 346.4102 200
node .24991958618164062500*box -.00027902221679687500*box .49998059082031250000*box -.74890136718750000000 -.34616088867187500000 153.36914062500000000000
node .75041552734375000000*box .00015951538085937500*box .50008172607421875000*box .47927856445312500000 .99719238281250000000 -125.78247070312500000000
node .49960971069335937500*box .50042877197265625000*box .49974542236328125000*box -1.24319458007812500000 .69607543945312500000 -83.96850585937500000000
node .00046789550781250000*box .50009417724609375000*box .50021948242187500000*box -.93054199218750000000 .88842773437500000000 -158.66455078125000000000

Recent atomsk gives an error:

$ atomsk --polycrystal Al.xsf poly00.txt poly.cfg -wrap
  ___________________________________________________
 |              ___________                          |
 |     o---o    A T O M S K                          |
 |    o---o|    Version master                       |
 |    |   |o    (C) 2010 Pierre Hirel                |
 |    o---o     https://atomsk.univ-lille.fr         |
 |___________________________________________________|
 *** I am hungry! :-p
 >>> Constructing a polycrystal using Voronoi method.
 >>> Opening the input file: Al.xsf
 ..> Input file was read successfully (2 atoms).
 >>> Reading parameters for Voronoi construction from: poly00.txt
 X!X ERROR: there were errors while reading the file: poly00.txt
           Error appears to be at line # 2
 \o/ Program terminated successfully!
     Total time: 0.001 s.; CPU time: 0.001 s.
  ___________________________________________________
 |  X!X ERRORS:   1                                  |
 |___________________________________________________|

Removing three zeroes at the end of angle X or Y does cure the problem. This is strange, probably something related to the optional degree sign? My workaround for now is to use for angle Y scale=10 (up to 17) to limit the number of digits printed by bc -l and with this atomsk works.

I had troudble in converting vasp output. I noticed in old closed issues, people were able to use QE. So I tried to use QE output in --one-in-all mode and it worked smoothly. I'm wondering what might go wrong. Thanks in advance!

$ atomsk --one-in-all OUTCAR 
  ___________________________________________________
 |              ___________                          |
 |     o---o    A T O M S K                          |
 |    o---o|    Version b0.11.2                      |
 |    |   |o    (C) 2010 Pierre Hirel                |
 |    o---o     https://atomsk.univ-lille.fr         |
 |___________________________________________________|
 *** Working out of office hours? You should sleep sometimes. :-)
 >>> Unfolding OUTCAR to many files...
 X!X ERROR: there were errors while reading the file:
 >>> No file was converted.
 \o/ Program terminated successfully!
     Total time: 0.002 s.; CPU time: 0.002 s.

Does atomsk support construct heterostructures based on CSL or Zur algorithms?

BTW, the CSL algorithm has been implemented in hetbuilder.

Regards,
Zhao

I am trying to create a fcc ternary alloy supercell using Atomsk
While It allows me to make binary alloys, the program doesn't allow me to have three or more components?
Is there a workaround?

Thanks

Hello, I am getting a "stack smashing detected" message or "segmentation fault" when I try deleting atoms at grain boundary using the 'remove-doubles command. I am running this on cluster with about 5 million atoms in the polycrystal. Here's a screenshot of the error (below).
I appreciate any help I can get on this.
Thank you.

First of all thank you for this amazing tool.

I would like to know your views on a problem that I am facing while installing atomsk. I saw that there is a file Makefile.local in the src folder and wanted to use that to install atomsk to my home folder instead of having it installed system wide. But the problem is while writing all the files, it tries to write a atomsk.conf file to the /etc folder for which it has no access.

Is there any way this file can be written to my home folder instead of being written to the system wide /etc folder. Though I can modify the Makefile to incorporate such a change, I am unsure as to whether such an action will enable the compiled atomsk binary to read the atomsk.conf file from my custom location.

I would prefer the compiled binary to read the configuration file from ~/.config/atomsk/atomsk.config instead when installed locally!

Please help me sort this out.

Dear Pierre,

I think I found another problem in polycrystal. I'm doing 12 prismatic grains with random orientation in one layer as before, but I realized the grains will have the interface at Z boundary only with itself i.e. with a grain having the same orientation. So I added second layer, with the same node positions in X and Y, in order to be able to shift both grains in Z as you suggested earlier.

X and Y are generated randomly by bash, Z is 1/4 and 3/4 of the box. Now I sometimes observe a grain overlap. For example here (as the orientation does not matter, I've reset it to 0 0 0):

box       173.200000      173.200000       50.000000
node        31.613440       36.587231       12.500000     0 0 0
node        31.613440       36.587231       37.500000     0 0 0
node        26.047656      114.545203       12.500000     0 0 0
node        26.047656      114.545203       37.500000     0 0 0
node        41.080029       80.389368       12.500000     0 0 0
node        41.080029       80.389368       37.500000     0 0 0
node        53.770862        3.895520       12.500000     0 0 0
node        53.770862        3.895520       37.500000     0 0 0
node        10.677002      121.178687       12.500000     0 0 0
node        10.677002      121.178687       37.500000     0 0 0
node        16.475354      104.618762       12.500000     0 0 0
node        16.475354      104.618762       37.500000     0 0 0
node        47.311804        2.515967       12.500000     0 0 0
node        47.311804        2.515967       37.500000     0 0 0
node       104.634619      145.138513       12.500000     0 0 0
node       104.634619      145.138513       37.500000     0 0 0
node        75.257007      142.574976       12.500000     0 0 0
node        75.257007      142.574976       37.500000     0 0 0
node        46.460815      156.122083       12.500000     0 0 0
node        46.460815      156.122083       37.500000     0 0 0
node         5.153503      110.311401       12.500000     0 0 0
node         5.153503      110.311401       37.500000     0 0 0
node       106.664307       81.224500       12.500000     0 0 0
node       106.664307       81.224500       37.500000     0 0 0

In this sample there is an important overlap of grains 1, 15, 23 from first layer and 2, 16, 24 from second layer. All the grains are somehow larger than they should be.

Interesting is, when I try to construct just the first layer (i.e. just the lines Z=12.5), there is no overlap.

As it happens only sometimes, for me it would be enough to know, there is an overlap and skip such sample. I've tried detecting the overlap by -remove-doubles, but in fact there is more overlapping atoms at the grain boundaries than in the problematic region. I can also detect the overlapping grains by looking at the total number of atoms, as it is higher than in correct sample, but it is difficult to find the threshold.

Or perhaps it is easier to construct the two layer sample by producing two one-layerers and then glue them together?

I'm creating a large cylindrical grain boundary structure of CeO2 that will be simulated using the core-shell model in LAMMPS. Using Atomsk, I am able to create the unit cell, and duplicate it to the desired size without issues. However, when I try to add the shells, once the number of molecule IDs reaches 10000, the value for the Atom section changes to "*****" instead of the actual molecule ID. The Bonds section lists the ID without any issues however.

Commands issued:
atomsk --create fluorite 5.408 Ce O lmp
mv CeO2.lmp CeO2_unit_cell.lmp
atomsk CeO2_unit_cell.lmp -dup 50 50 5 CeO2_core_50x50x5_100.lmp

I then run a script that generates a cylindrical grain boundary, giving an output file of e.g. CeO2_core_50x50x5_45degree_rcut0.85_removed.dat.

atomsk ${input} -add-shells all -properties core_shell_CeO2_properties.txt ${output}
where ${input} and ${output} are the input file and desired output file names respectively.

Contents of core_shell_CeO2_properties.txt:

# Charges for CeO2 crystal
charge
Ce -0.6475 4.6475
O  4.5667 -6.5667

And the relevant output from the final atomsk command:

...
Atoms # full
...
    199996  99998    4   0.000000      167.704285000000     135.200000000000      17.576000000000
    199997  99999    2   0.000000      169.616301000000     137.112017000000      17.576000000000
    199998  99999    4   0.000000      169.616301000000     137.112017000000      17.576000000000
    199999  *****    2   0.000000      169.616301000000     133.287983000000      20.280000000000
    200000  *****    4   0.000000      169.616301000000     133.287983000000      20.280000000000
    200001  *****    2   0.000000      171.528318000000     135.200000000000      20.280000000000
...
Bonds
...
       99998           2      199995      199996 
       99999           2      199997      199998 
      100000           2      199999      200000 
      100001           2      200001      200002 
...

I've attached the resultant file from my own script as CeO2_file.gz

CeO2_file.gz

Is there a setting I missed that will allow me to output the correct molecule ID?

$ atomsk --version
 (C) P. Hirel 2010 - Version master

Fresh install of Atomsk (master version) on Mac Sierra 10.12.6
I have tried to follow the grain boundary tutorial, but have been unable to create the boundary. Attached is a screenshot of my terminal. The file polyX.txt is exactly the same as the tutorial (I have tried with and without the degree symbols). I have also attached the three output files: polycrystal.cfg, polycrystal.dat, and polycrystal_nodes.xsf. Looking at the cfg file in Ovito shows a strange structure (also attached). Is this an issue on my end?

polycrystal_nodes.xsf.txt
polycrystal.cfg.txt
polycrystal.dat.txt

See below:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.3 LTS
Release:	22.04
Codename:	jammy


werner@X10DAi:~/Public/repo/github.com/pierrehirel/atomsk.git/src$ make all -j 44
mkdir -p OBJ
       o---o     ___________
      o---o|     A T O M S K
make -j44 --jobserver-auth=3,9 -j1 -C include
      |   |o
      o---o      Version master
make[1]: warning: -j1 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/include'
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/globalvar.o  -c globalvar.f90 

gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/constants.o  -c constants.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/math.o  -c math.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/random.o  -c random.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/functions.o  -c functions.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/atoms.o  -c atoms.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/subroutines.o  -c subroutines.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/crystallography.o  -c crystallography.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/elasticity.o  -c elasticity.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/sort.o  -c sort.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/display_messages.o  -c display_messages.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/messages_EN.o  -c messages_EN.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/messages_FR.o  -c messages_FR.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/messages_DE.o  -c messages_DE.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/messages.o  -c messages.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/expreval.o  -c expreval.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/resize.o  -c resize.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/spacegroups.o  -c spacegroups.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/neighbors.o  -c neighbors.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/files.o  -c files.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/symops.o  -c symops.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/guess_format.o  -c guess_format.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/read_cla.o  -c read_cla.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/determine_H.o  -c determine_H.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/readconf.o  -c readconf.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/qepw_ibrav.o  -c qepw_ibrav.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/in_stl.o  -c in_stl.f90 
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -fno-tree-pre -cpp -o ../OBJ/average_env.o  -c average_env.f90 
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/include'
make -j44 --jobserver-auth=3,9 -C compute
..> Compiling input, options and output modules...
make -j44 --jobserver-auth=3,9 caux
make[1]: warning: -j44 forced in submake: resetting jobserver mode.
make[1]: warning: -j44 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/compute'
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/compute_G.o  -c compute_G.f90
make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make -w -j44 --jobserver-auth=4,11 -C input
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/compute_rdf.o  -c compute_rdf.f90
make -w -j44 --jobserver-auth=4,11 -C options
make -w -j44 --jobserver-auth=4,11 -C output
make[2]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make[2]: warning: -j44 forced in submake: resetting jobserver mode.
make[2]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make[2]: warning: -j44 forced in submake: resetting jobserver mode.
make[2]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make[2]: warning: -j44 forced in submake: resetting jobserver mode.
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_abinit.o  -c in_abinit.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/disloc_iso.o  -c disloc_iso.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_abinit.o  -c out_abinit.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_atsk.o  -c in_atsk.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/disloc_aniso.o  -c disloc_aniso.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_atsk.o  -c out_atsk.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_bop.o  -c in_bop.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_bop.o  -c out_bop.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/disloc_loop.o  -c disloc_loop.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_bopfox.o  -c out_bopfox.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_bopfox.o  -c in_bopfox.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_addatom.o  -c opt_addatom.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_cel.o  -c out_cel.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_cel.o  -c in_cel.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_addshells.o  -c opt_addshells.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_cfg.o  -c out_cfg.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_alignx.o  -c opt_alignx.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_cfg.o  -c in_cfg.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_cif.o  -c out_cif.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_bindshells.o  -c opt_bindshells.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_cif.o  -c in_cif.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_crystal.o  -c out_crystal.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_cart2frac.o  -c opt_cart2frac.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_crystal.o  -c in_crystal.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_csv.o  -c out_csv.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_csv.o  -c in_csv.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_cell.o  -c opt_cell.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_dat.o  -c out_dat.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_center.o  -c opt_center.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_dlpoly_config.o  -c in_dlpoly_config.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_dd.o  -c out_dd.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_gulp_gin.o  -c in_gulp_gin.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_crack.o  -c opt_crack.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_dlpoly_config.o  -c out_dlpoly_config.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_gulp_gin.o  -c out_gulp_gin.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_imd.o  -c in_imd.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_cut_cell.o  -c opt_cut_cell.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_jems.o  -c in_jems.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_imd.o  -c out_imd.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_deform.o  -c opt_deform.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_jems.o  -c out_jems.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_lammps_custom.o  -c in_lammps_custom.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_disloc.o  -c opt_disloc.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_lammps_data.o  -c out_lammps_data.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_lammps_data.o  -c in_lammps_data.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_disturb.o  -c opt_disturb.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_mbpp_coorat.o  -c out_mbpp_coorat.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_mbpp_coorat.o  -c in_mbpp_coorat.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_duplicate.o  -c opt_duplicate.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_moldy_system.o  -c out_moldy_system.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_moldy_system.o  -c in_moldy_system.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_fix.o  -c opt_fix.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_pdb.o  -c out_pdb.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_pdb.o  -c in_pdb.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_qe_pw.o  -c out_qe_pw.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_mirror.o  -c opt_mirror.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_qe_pw.o  -c in_qe_pw.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_siesta_fdf.o  -c out_siesta_fdf.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_orient.o  -c opt_orient.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_siesta_xv.o  -c out_siesta_xv.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_orthocell.o  -c opt_orthocell.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_siesta_fdf.o  -c in_siesta_fdf.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_str.o  -c out_str.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_properties.o  -c opt_properties.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_siesta_xv.o  -c in_siesta_xv.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_vasp_poscar.o  -c out_vasp_poscar.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_reduce_cell.o  -c opt_reduce_cell.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_str.o  -c in_str.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_vesta.o  -c out_vesta.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_remdoubles.o  -c opt_remdoubles.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_xmd.o  -c out_xmd.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_vasp_poscar.o  -c in_vasp_poscar.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_xsf.o  -c out_xsf.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_rmatom.o  -c opt_rmatom.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_vesta.o  -c in_vesta.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/out_xyz.o  -c out_xyz.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_rmprop.o  -c opt_rmprop.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_xmd.o  -c in_xmd.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_rmshells.o  -c opt_rmshells.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_xsf.o  -c in_xsf.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_roll.o  -c opt_roll.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/in_xyz.o  -c in_xyz.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_rotate.o  -c opt_rotate.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_roundoff.o  -c opt_roundoff.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_select.o  -c opt_select.f90
opt_disloc.f90:49:5:

   49 | USE dislocation_iso
      |     1
Fatal Error: Cannot open module file ‘dislocation_iso.mod’ for reading at (1): No such file or directory
compilation terminated.
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_separate.o  -c opt_separate.f90
make[2]: *** [Makefile:12: opt_disloc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/writeout.o -c writeout.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/readin.o  -c readin.f90
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/compute'
make[2]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/output'
make[2]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/input'
make[2]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/options'
make[1]: *** [Makefile:199: options] Error 2
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make: *** [Makefile:188: aux] Error 2
werner@X10DAi:~/Public/repo/github.com/pierrehirel/atomsk.git/src$ make all -j 44
mkdir -p OBJ
       o---o     ___________
      o---o|     A T O M S K
make -j44 --jobserver-auth=3,9 -j1 -C include
      |   |o
      o---o      Version master
make[1]: warning: -j1 forced in submake: resetting jobserver mode.

make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/include'
make[1]: Nothing to be done for 'general'.
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/include'
make -j44 --jobserver-auth=3,9 -C compute
..> Compiling input, options and output modules...
make -j44 --jobserver-auth=3,9 caux
make[1]: warning: -j44 forced in submake: resetting jobserver mode.
make[1]: warning: -j44 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/compute'
make[1]: Nothing to be done for 'compute'.
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/compute'
make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make -w -j44 --jobserver-auth=4,11 -C input
make -w -j44 --jobserver-auth=4,11 -C options
make -w -j44 --jobserver-auth=4,11 -C output
make[2]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make[2]: warning: -j44 forced in submake: resetting jobserver mode.
make[2]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make[2]: warning: -j44 forced in submake: resetting jobserver mode.
make[2]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make[2]: warning: -j44 forced in submake: resetting jobserver mode.
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_disloc.o  -c opt_disloc.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/readin.o  -c readin.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/writeout.o -c writeout.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_shift.o  -c opt_shift.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_sort.o  -c opt_sort.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_spacegroup.o  -c opt_spacegroup.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_stress.o  -c opt_stress.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_substitute.o  -c opt_substitute.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_swap.o  -c opt_swap.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_torsion.o  -c opt_torsion.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_unit.o  -c opt_unit.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_unskew.o  -c opt_unskew.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_velocity.o  -c opt_velocity.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/opt_wrap.o  -c opt_wrap.f90
make[2]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/input'
make[2]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/output'
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/options.o  -c options.f90
make[2]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/options'
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src'
make -j44 --jobserver-auth=3,9 -C modes
make[1]: warning: -j44 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/modes'
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_difference.o  -c mode_difference.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_normal.o  -c mode_normal.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_cpprop.o  -c mode_cpprop.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_matchid.o  -c mode_matchid.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_create.o  -c mode_create.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_merge.o  -c mode_merge.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/1ia_dlpoly_history.o  -c 1ia_dlpoly_history.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/1ia_qe_out.o  -c 1ia_qe_out.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/1ia_vasp_outcar.o  -c 1ia_vasp_outcar.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/1ia_lmc.o  -c 1ia_lmc.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/1ia_xsf.o  -c 1ia_xsf.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/1ia_xyz.o  -c 1ia_xyz.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_unwrap.o  -c mode_unwrap.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_allinone.o  -c mode_allinone.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_epola.o  -c mode_epola.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_electricdipoles.o  -c mode_electricdipoles.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_rdf.o  -c mode_rdf.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_polycrystal.o  -c mode_polycrystal.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_interpolate.o  -c mode_interpolate.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_nye.o  -c mode_nye.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_average.o  -c mode_average.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_density.o  -c mode_density.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_localsym.o  -c mode_localsym.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/mode_list.o -c mode_list.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -o ../OBJ/modes.o -c modes.f90
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o ../OBJ/mode_interactive.o -c mode_interactive.f90
make[1]: Leaving directory '/home/werner/Public/repo/github.com/pierrehirel/atomsk.git/src/modes'
gfortran -O2 -DOPENMP -fopenmp -fno-backslash -I../OBJ -J../OBJ -cpp -o atomsk OBJ/*.o atomsk.f90 -I OBJ -llapack
f951: Warning: Nonexistent include directory ‘../OBJ’ [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory ‘../OBJ’ [-Wmissing-include-dirs]

    \o/ Compilation was successful!

    <i> To install Atomsk system-wide, you may now run:
          sudo make install

So, it seems that atomsk did not specifically design and optimize the corresponding makefile for parallel compilation.

Regards,
Zhao

I came across this ghostly bug with atomsk. To reproduce do the following:

create an empty directory and execute for example

atomsk --create fcc 1.386720 Al orient [1-21] [10-1] [111] -duplicate 7 14 7 -ow e_0.0370_h_-44_lat.xsf

this perfectly works. Now do

mkdir 1 && atomsk --create fcc 1.386720 Al orient [1-21] [10-1] [111] -duplicate 7 14 7 -ow e_0.0370_h_-44_lat.xsf

or

mkdir 2 && atomsk --create fcc 1.386720 Al orient [1-21] [10-1] [111] -duplicate 7 14 7 -ow e_0.0370_h_-44_lat.xsf

in this case atomsk says:

X!X ERROR: base vectors are not orthogonal.

The logfile points out that the arguments of orient are not being interpreted properly. In the first case the logfile is perfect

debug: Command-line arg #  5   : orient  
debug: Command-line arg #  6   : [1-21]  
debug: Command-line arg #  7   : [10-1]  
debug: Command-line arg #  8   : [111]

But in the second case it reads

debug: Command-line arg #  5   : orient  
debug: Command-line arg #  6   : 1  
debug: Command-line arg #  7   : 1  
debug: Command-line arg #  8   : 1  

I want to use atomsk to construct a poly crystal. But i have a question here. Some atoms in one grain may be too close to some atoms in other grain at grain boundary. These overlapping atoms may cause problems for quenching. Does atomsk consider this?

Dear Dr. Pierre,

I used Atomsk to create a polycrystal with the box size of 200x200x200 (A) consisting of 120 grains. So, how can I determine the average grain size? Thank you very much for your time.

Shu

I am trying to create a solid solution supercell(Cd0.5Zn0.5S), but it is gonna be too much work if I pick the atoms and do replacement randomly by hand, is it possible to do this job with atomsk?

Hi,

thank you very much for this package. I have a question regarding the reorientation of the hcp lattice. Your documentation here states that the (HKIL) vectors of the hcp convention are not supported.
But since they are redundant anyways, I was wandering if it is possible to rotate a hcp lattice with the reduced set, i.e. (HKIL) -> (HKL), since I = -(H+K). Some other packages, like the atomic simulation environment do that. They rotate a structure regardless of the underlying symmetry.

My command is the following:

atomsk -nthreads 1 --create hcp 3.187 5.197997 Mg -orthogonal-cell -orient [020] [-102] [100] -duplicate 20 1 5  mg_cell.xsf

But nothing is rotated
Even making it in two steps, does not result in a rotation:

atomsk -nthreads 1 --create hcp 3.187 5.197997 Mg -orthogonal-cell -duplicate 3 5 2  mg_cell.xsf
atomsk mg_cell.xsf -nthreads 1 -orient [2-10] [-120] [001] [2-10] [241] [-102] final.xsf

What I basically want is to rotate the crystal around the x-axis ~27 degrees and the mirror it.
The error message reads:

 X!X ERROR: the base Hend is not a rotation of Hstart.
     Check that angles are equal in Hstart and Hend.

and I don't know what do do with that.
Thanks,
Markus

Edit: I just wanted to add that I want to create a hcp twin boundary. Maybe there is an easier way, but it is not obvious to me.

Dear Sir,

I was trying to construct an atomic model of hcp-Mg polycrystal with the command polycrystal in Atomsk. I read the tutorial and used the following command:

atomsk --create hcp 3.2 5.225 Mg Mg.xsf
atomsk --polycrystal Mg.xsf poly.txt final.cfg -wrap

with file poly.txt containing:

box 600 600 600
random 8

But the output file seems bizarre because some atoms are missing at the grain boundary. As shown in this picture:

A cavity exists at the grain boundary in the interior of the model. I have tried the same commands serval times, although the generated models are different, the cavity always exists.

I read the Issue#28 which seems to have the same problem, so I tried to do the same thing on a different computer. But I still have the same problem.

The version of the first computer is:

Windows 10 Home edition
Atomsk Version Beta-0.10.6

The version of the second computer is:

Ubuntu 18.04.1
Atomsk Version Beta-0.11

I found that changing the version of Atomsk or Operating System did not fix the problem.

Thank you!

Hello Sir,
when creating a poly crystalline alloy ex- Ti-Al,where is am interested in changing the composition of the alloy, is it possible to change the lattice parameters of both Ti and Al, especially Al since Al is the substituting material?if yes then how I can change the lattice constant of Al?
please help.
regards,
Debopriyo Banerjee
NIT Durgapur

Want to generate a polycrystalline system with 1 um x 1um x 1 um dimensions. With the HPC, can generate a quarter of the system- 0.25 um x 0.25 um x 0.25 um.

Anything above, the system shows a segmentation error related to the memory. Would there be any way around it?

Thanks for developing this great package. It has been very useful in my work.

It is currently possible to convert a file containing many snapshots to several file using the --one-in-all option and also to convert many files into one file containing all snapshots using the all-in-one option. It would be nice to have an option to convert a file containing several snapshots to another format which can contain several formats, instead of writing to separate files. My use case is to convert a LAMMPS dump file to animated xsf file or extended xyz file.

I currently use the workaround of first converting the file to several files using one-in-all option and then converting all the separate files to one using the all-in-one option and then delete the intermediate files. But it would be great if it is possible to do this directly in atomsk.

Hi,

I noticed a couple issues with Polycrystal mode.

1/ When I use the polycrystal mode using the nodes information file below, some grains are not trimmed correctly, as shown in the screenshot (the triangular yellow regions).
polycrystal.txt
Ni.txt (I changed the extension from .cfg to .txt so that I can upload it here)

I notice in the code that the maximum vertices (neighboring nodes?) is limited to 21 for 2-D and 59 for 3-D (line 999 and 1001 in mode_polycrystal.f90). I suspect that this is the cause so I increase these limits to 100 and all the grains are trimmed correctly using the recompiled file. I didn't check the source for why you set these limits but it doesn't seem to work in this particular case.

The command I used to generate this error

atomsk --polycrystal Ni.cfg polycrystal.txt final.cfg

2/ Sometimes I ran into this error below.

The files and command that I used to generate this error:
Ni.txt
polycrystal2.txt

atomsk --polycrystal Ni.cfg polycrystal2.txt final.cfg

I'm not sure what's going here but sometime it works and sometimes it terminate with this error (when I use different sets of nodes)
Here is the MatLab code that I used to generate the set of nodes. You can create different set of nodes and sometimes it works, sometimes it doesn't.
Seed_generation.txt (Again, I changed the extension from .m to .txt in order to upload here)

Best,

Thanh

I've discovered a strange bug when using Atomsk to generate a unit cell. The command I use is:

atomsk  --create  fcc 3.535 Fe orient [11-2] [1-10] [111]  -fractional  fcc_111_Fe.cfg

This immediately raises the error:

Program received signal SIGBUS: Access to an undefined portion of a memory object.

Hope some light can be shed on this. Cheers

Hi,

I have the following disp.txt to use with the option -properties:

#Atom displacements(in angströms)

displacement functions

uz = 3.3atan2(x,y)/(2pi)

The idea is to generate a helix from an annulus. So I center the annulus in the coordinate (0,0,0) which is a corner of the simulation box and then apply the -properties option. In the line x=0 there is an error that shows:

X!X ERROR: division by zero.

The problem is that according to the definition of atan2 this should not be the case since when x=0, atan2 goes to +- pi/2. Is this a bug in the code?

Thanks for the help,

Wilson Nieto

I noticed that Version 0.11 is available on the website but the tagged versions on this repository end at version 0.10 https://github.com/pierrehirel/atomsk/tags . Is it possible to publish tags for the latest versions as well? This would be helpful to create the conda package conda-forge/atomsk-feedstock#14

Dear Pierre Hirel

First of all, congratulation on the creation of Atomsk. It's a great tool to create and manipulate crystal structures!!!

First Issue
I fund some issues trying crystal orientation. I need to create a c14 precipitate of ZrNbFe2 inner a Z matrix to simulate HRTEM image with JEMS. In C14 structure I remove the Fe in position 000 and 001/2 and replace by Nb. That works very well. The normal orientation given by atomsk was:

..> C14 ZrFe2 with box vectors H1=[2-1-10], H2=[-12-10], H3=[0001].
..> System was successfully created.

However, when I try to reorient the crystal it doesn't work:

atomsk C14-creado.cfg -orient [2-1-10] [-12-10] [0001] [-1011] [1-101] [01-11] C14-rotada.cfg

Opening the input file: C14-creado.cfg
..> Input file was read successfully (12 atoms).
Rotating the system to change the crystal orientation...
X!X ERROR: the base Hend is not a rotation of Hstart.
Check that angles are equal in Hstart and Hend.
X!X ERROR: there were errors while applying options.
\o/ Program terminated successfully!
Total time: 0.003 s.; CPU time: 0.003 s.

I don't understand is I made a mistake or if is an issue in "orient" calculation with a hexagonal base.

Second Issue
I replete the example from the tutorial about Crystal Orientation:
atomsk --create bcc 2.85 Fe Fe.cfg
and then
atomsk Fe.cfg -orient [100] [010] [001] [121] [-101] [1-11] Fe_orient.cfg
I checked with Ovito that the re-orientation work pretty well. However, when I converted both files to JEMS's input files
atomsk Fe.cfg -unit A nm JEMS and atomsk Fe_orient.cfg -unit A nm JEMS both files were rendered in the same orientation by JEMS ([001] axis zone)

Thank you in advance

I want to build a polycrystal model containing 4 grains with different orientations. For example, the first, second, and third grain is x-[001], the fourth grain is x-[111]. Can you tell me how the size of the box sets along x in the parameter file "polycrystal.txt" to match the periodicity?