Odd terminations of grain boundaries

[j-m-dean]

I am attempting to use aimsgb to produce a large quantity of grain boundaries, however I have been obtaining odd terminations at the grain boundary. For example, for the anti-perovskite structure with sigma = 3, axis = (111), and plane = [1 1 1] the grain boundary output is one with oxygens in the centre of the grain boundary. See image

.

The correct structure can be produced by deleting the required layers ie "delete_layer = 1b1t1b1t". See image

Given that I wish to produce a large number of grain boundaries, manually visually inspecting what aimsgb is outputting, checking it is sensible, and then rectifying the terminations will likely take an exceedingly long time.

I produced the same grain boundary not too long ago with the correct termination behaviour using aimsgb, so I wonder if the route cause of the problem could have been recent software updates on one of the codes aimsgb is dependant on.

The unit cell file I have been using to produce the grain boundaries is: CONTCAR.zip

I have also noticed that the returned grain boundary for sigma = 3, axis = (210), and plane = [2 1 0] is identical to the grain boundary structure with the inputs sigma = 5, axis = (210), and plane = [2 1 0], which is not possible.

Any help you could provide would be greatly appreciated.

[jic198]

Hello,

I don't think it is due to the recent update. I got the same oxygen termination from my end. If you want to avoid certain terminations during your production, one thing you can try is using grain.sort_sites_in_layers() method. For example, after you define your GB: gb = GrainBoundary([1, 1, 1], 3, [1, 1, 1], s) You can do: layers = gb.grain_a.sort_sites_in_layers() Then you can check if the bottom, layers[0], or top layer, layers[-1], is the oxygen layer. Then you can use gb.grain_a.delete_bt_layer to delete the bottom or top layer. Let me know if this doesn't work.

Thanks, Jianli

On Tue, Aug 3, 2021 at 11:17 PM j-m-dean @.***> wrote:

I am attempting to use aimsgb to produce a large quantity of grain boundaries, however I have been obtaining odd terminations at the grain boundary. For example, for the anti-perovskite structure with sigma = 3, axis = (111), and plane = [1 1 1] the grain boundary output is one with oxygens in the centre of the grain boundary. See image [image: ap_odd_termination] https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_43647367_128130745-2Db85ae354-2D47e4-2D4c64-2D9272-2Ddcbabe15fb65.png&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=m-Go8pZyDBDPfw-ChOBssDpTGsrL3OUS_fNoITJVXJk&e= .

The correct structure can be produced by deleting the required layers ie "delete_layer = 1b1t1b1t". See image [image: ap_rectified] https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_43647367_128131050-2De1070115-2Dc2e6-2D403c-2Da163-2D368c8d7fee25.png&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=A_8rJc_ENTP6JAYJxeEpTEPp2TIGtBIiWKTbaRQGico&e= Given that I wish to produce a large number of grain boundaries, manually visually inspecting what aimsgb is outputting, checking it is sensible, and then rectifying the terminations will likely take an exceedingly long time.

I produced the same grain boundary not too long ago with the correct termination behaviour using aimsgb, so I wonder if the route cause of the problem could have been recent software updates on one of the codes aimsgb is dependant on.

The unit cell file I have been using to produce the grain boundaries is: CONTCAR.zip https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ksyang2013_aimsgb_files_6929025_CONTCAR.zip&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=iF23-qFR_Ii4LTd6ot4eYMg1tVTQ-Rmtbgo942fOQd8&e=

Any help you could provide would be greatly appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ksyang2013_aimsgb_issues_5&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=eJE2cgLy2dVb1ZpRfeGN-Ctn0FETimbyq-dS2TkCJIU&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AEM7HVAGI4BYWHPGA4FOYI3T3DLPVANCNFSM5BQK7IDA&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=dcnQNj6rxQJ7byKEZXWCIJIIojUW2cd_z7HNaC7GFPo&e= . Triage notifications on the go with GitHub Mobile for iOS https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=MTesoTcl_5-vanhKHd27MgsuRevdWkD99KE6qsvotic&e= or Android https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26utm-5Fcampaign-3Dnotification-2Demail&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=LVP_TnAYXACbQSyOogzgKQ&m=VZfGXWNlBZ5M5Iky7wy9otiu2ATJHzCQM5Nx6Ycqxug&s=3u_zP17lujSCc1UNAVWYnmnT4pfJDsROYt12Lv8302U&e= .

[j-m-dean]

Hello Jianli,

Thank you for the helpful advice and quick response. The above did work, thank you.

Do you know why aimsgb produces the same grain boundary for sigma = 3, axis = (210), and plane = [2 1 0] and sigma = 5, axis = (210), and plane = [2 1 0] ? Whilst I know that grain boundaries with the same sigma and different planes and axes may represent the same grain boundary, I thought it was impossible for grain boundaries with different sigma values to represent the same structure.

Thanks,

Jacob

[jic198]

I apologize for the late reply. The reason for the two GBs to have the exact structure is because they have the same coincidence site lattice matrix. See below: Also, the structure of sigma 5[210]/(210) is the same with sigma 5[001]/(210)