Addressing Vacancy Representation and Exchange Challenges in Al2O3 Simulations Using LAMMPS

LAMMPS LAMMPS Development
1

Dear contributors to the LAMMPS community,

I hope this message finds you well.

I am currently attempting to identify the lowest energy vacancy occupation sites in Al2O3 using LAMMPS. However, in my simulations, I am unable to explicitly mark the “vacancy” feature.

To work around this, I considered introducing a type 3 atom to represent the vacancy, in addition to the existing Al and O types. This type 3 atom is designed to have no interactions with Al, O, or itself. My plan was to conduct MD/MC simulations under these conditions. However, I encountered an issue: Al atoms and vacancy atoms rarely exchange successfully (almost never).

I believe this problem arises because the lack of interaction between Al and the vacancy atom leads to potential overlap of their positions. To address this, I am considering adding a weak interaction to the vacancy atom to prevent such overlap.

I would like to ask for your advice on two points:

  1. Would adding a weak interaction to the vacancy atom to prevent overlapping affect the simulation results of Al2O3?
  2. How should I properly implement this weak interaction in LAMMPS?

Thank you very much for your assistance.

Best regards

2

Definitely yes.

I think this is the wrong approach.
I don’t have much experience in the kind of simulations you are after, but the argument you make for your proposal is more about addressing a symptom than really solving a problem.

From my outside perspective there are a bunch of questions you need to address:

  • how can you reliably identify vacancies? and create atom positions from those?
    It is quite possible to have an additional atom type without any interactions (e.g. via a hybrid pair style that includes pair style zero) that will still have a neighbor list of those atom for further processing.
  • you will have to implement a “time integration fix” that updates the positions of those “vacancy atoms” as the system propagates. There is some overlap with the functionality to identify vacancies at all, but how would you make it so that vacancies retain their identity and new vacancies may be added or vacancies may be eliminated?
  • based on existing atom types for vacancies, you could implement an MC move based on fix atom/swap. But the open question is which additional properties will need to be updated compared to what fix atom/swap currently handles?