Cut the supercell from GULP about sisl

[zerothi]

When cutting you should do it in opposite order of the tiling, for instance.

[KitchenSong]

I wonder how to make tile work in this case. In current situation, I have not used tile at all. Maybe I am wrong...

[zerothi]

Then yes, you are doing it wrong.

Think that:

g = sisl.geom.graphene()
gxyz = g.tile(4, 0).tile(3, 1).tile(2, 2)
G = gxyz.cut(2, 2).cut(3, 1).cut(4, 0)
assert np.allclose(g.xyz, G.xyz)

I.e. your input geometry in GULP must come from the tiling routine.

[zerothi]

As for the optimization flag. No, that will prevent the cut method to extract supercell connections as the atomic coordinates will not be translational invariant. You should, however, do an optimization before tiling the structure for extracting the dynamical matrix.

[KitchenSong]

I am following your suggestions: using tile first. But when doing those tiling operation, how to keep track of the atom species information?

[zerothi]

What do you mean? The sisl geometry keeps track of everything for you?

[KitchenSong]

Here is how I try to do it:

I first run a GULP calculation for a small cell.

Then I read the geometry and generate the supercell using
gxyz = geo1.tile(3, 0).tile(3, 1).tile(3, 2) leftpos = gxyz.xyz

What you suggests is that in the variable leftpos, there is no longer more atom species information?

[zerothi]

I don't get what you mean? gxyz contains all species informations.
How would you want the species?

gxyz = geo1.tile(3, 0).tile(3, 1).tile(3, 2)
# gxyz contains species information!
leftpos = gxyz.xyz
species = [atom.symbol for atom in gxyz.atom]

For further details look for the Atoms and Atom class in the sisl documentation.

[KitchenSong]

Well, I think you just answered my question. Sorry for the confusion.

[zerothi]

Great!