Add grain boundary generator

[ucsdlxg]

Summary

This generator provides two methods to generate grain boundaries (GBs) from bulk conventional cell (fcc, bcc can from the primitive cell), and works for Cubic, Tetragonal, Orthorhombic, Rhombohedral, and Hexagonal systems. The first one is to generate GBs from given parameters, which includes
GB plane, rotation axis, rotation angle. The second one is to generate GBs from given transformation matrices for each grain. It works for any general GB, including both twist, tilt GBs, etc.

It also contains functions that can generate all possible sigma values and from sigma value to generate rotation angles needed for the GB generator.

[mkhorton]

Hi, I'm working with Hui on visualization of grain boundaries. Would it be possible to add a 'grain' site property here? something like,

all_coords = []
grain_labels = []
for site in bottom_grain:
    all_coords.append(site.coords)
    grain_labels.append('bottom_grain')
[...]
gb_with_vac = Structure(..., site_properties={'grain_label':grain_labels})

It would make it easier to visualize the grains during generation.

[mkhorton]

This looks like a great PR. I was wondering if it would be possible to mark which sites as co-incident between the top and bottom grains also? To make it possible to make a co-incident site lattice figure.

[ucsdlxg]

It is easy to label the grain sites( top or bottom, already implemented).
For the co-incident sites, I do not have a good way to label them for now.
Welcome for any suggestions.

[mkhorton]

Many thanks for adding grain labels.

For coincident sites, is it possible to create an additional structure where you extend both the top and bottom grains to fill the entire cell?

[mkhorton]

If you can create that structure (i.e. a structure with top and bottom grains fully-extended so that they overlap each other), finding co-incident sites would be fairly straight forward. I'd be happy to sketch out an implementation if you get to that stage.

[mkhorton]

Completely agreed, these were just the default colours don’t worry. We can change them to something more sensible!

[Tinaatucsd]

Oh yeah, the second graph is easier to recognize the two grains has a rotation angle. Also, I am wondering will it be difficult to add the icons which allow the users to rotate around specific directions (e.g.: x, y, and z-axis or rotation axis in a more general way) like the icons that are available in Vesta? Which might be convenient for users to look through the characteristics of GB structures by rotate it along the rotation axis.

[mkhorton]

This is fully 3D so you can rotate it :) If you’re on the update call tomorrow, I’ll give a demonstration.

[Tinaatucsd]

You mean the MP Dissemination Thrust call on this Friday? If so, yes, I will be there, and looking forward to the pretty 3D structures!
Also, about the rotation, I actually mean an extra button, which allows the user to specify the rotation axis. The users just need to click the icon once, the structure will be rotated around that specific axis and angle, or even do animation. I record an example to show as here: https://www.youtube.com/watch?v=WhR1WH2Sz3A.
If you can achieve this type of animation, it will be fabulous ;)

[mkhorton]

Oh, it's Friday! Even better. Rotating about an axis should be fine, as long as I have the axis of rotation in the Cartesian space of the crystal. I'll take a look tomorrow and see if I can make it work.

[mkhorton]

Yep, that’s correct. And then we find which sites overlap in the 4N structure within a given threshold (eg using scipy’s kdTree), and then use that to flag which sites are co-incident in the 2N structure.

…

On Wed, Jul 11, 2018 at 13:52, Xiang-Guo Li ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In pymatgen/core/grain_boundary_generator.py <#1200 (comment)> : > + normal_v_plane = np.cross(half_lattice.matrix[0], half_lattice.matrix[1]) + unit_normal_v = normal_v_plane / np.linalg.norm(normal_v_plane) + translation_v = unit_normal_v * vacuum_thickness + + # construct the final lattice + whole_matrix_no_vac = half_lattice.matrix + whole_matrix_no_vac[2] = half_lattice.matrix[2] * 2 + whole_matrix_with_vac = whole_matrix_no_vac.copy() + whole_matrix_with_vac[2] = whole_matrix_no_vac[2] + translation_v * 2 + whole_lat = Lattice(whole_matrix_with_vac) + + # construct the coords, move top grain with translation_v + all_coords = [] + for site in bottom_grain: + all_coords.append(site.coords) + for site in top_grain: You mean one structure with twice top grain and twice bottom grain. e.g. both top grain and bottom grain have N atoms. The grain boundary structure has 2N atoms. The new structure has 4N atoms with some atoms overlapping with each other. Is that correct? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1200 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC1rRNbuhXnSVVb7HlGeY-q_xkWMEgukks5uFmWkgaJpZM4VKRZt> .

[mkhorton]

Now I've had some time to take a closer look at this, I had a few quick questions/comments:

• Regarding "# angle tolerance should be looser" + tol_angle = 100 * tol -- why not just change the default kwarg here?
• How does lat_type work? Why not just get the lattice type via spacegroup analyzer?
• Will this work if you input the conventional unit cell and not the primitive? The vol_ratio = line seems to make certain assumptions about the input structure that I'm not sure I understand.

Thanks!

[ucsdlxg]

First, I just think the tolerance for angle should be smaller than that for distance when determining the lattice type, and do not want to use two tolerance parameters.

Second, when the function has 'lat_type' input parameter, then it has no concrete structure within it. If it has a structure, we will determine the lat_type from its structure properties (no lat_type input parameter needed). I just use the structure's lattice (a, b, c) and angle (alpha, beta, gamma) to determine the lat_type without using the spacegroup analyzer. I do not want the user to swap the a,b,c or angles. e.g. for hexagonal lattice, a=b!=c. gamma=120. Maybe spacegroup can do similar thing, I am not very familiar with it. Anyway, this part is quick.

Third, you can use conventional cell to generate the GB. Only fcc and bcc can also use the primitive cell. But if you use conventional cell for bcc or fcc, the code cannot guarantee the smallest GB structure.

Definitely, the code may need to be optimized further. Open for any suggestions.

Thanks!

[shyuep]

I suggest we do the following:
i. The user supplies whatever cell he wants, and we define (100) etc. based on the supplied structure. If he chooses to use primitive, we assume (100) refers to the primitive a direction. We should not allow alternative structure input based on lat_type. That is a recipe for disaster as there will be multiple methods for generating structure.
ii. Angle tolerance should be a default parameter.
iii. Pls move the gb generator to pymatgen.analysis.gb for now and update all tests accordingly. We will decide whether it should be part of core in future.