It seems that the functionality of this package is a subset of the ones implemented in Hetero2d.

[hongyi-zhao]

I noticed the package Hetero2d which has the following Package Description:

The 2D-substrate hetero-structure workflow takes a given 2D material, 3D phase (bulk) of the 2D material, and a substrate, relaxes the structures using vdW-corrected DFT and creates hetero-structures subject to user constraints. The workflow analyzes and stores energetic stability information of various 2D hetero-structured materials to predict the feasibility of a substrate stabilizing a meta-stable 2D material

Hetero2d provides automated routines for the generation of low-lattice mismatched hetero-structures for arbitrary 2D materials and substrate surfaces, the creation of van der Waals corrected density-functional theory (DFT) input files, the submission and monitoring of simulations on computing resources, the post-processing of the key parameters to compute (a) the interface interaction energy of 2D-substrate hetero-structures, (b) the identification of substrate-induced changes in interfacial structure, and (c) charge doping of the 2D material.

From the above description, it seems that the functionality of this package is a subset of the ones implemented in Hetero2d, aka, corresponding to the (a) mentioned above. Am I right?

Regards, Zhao

[fyalcin]

Hey @hongyi-zhao ,

After looking at the repo and the attached publication, it seems to me that we do different things. It looks like they are just interested in adhesion energies, and I don't see anything in their code that can calculate surface energies let alone handle arbitrary surfaces as we do here. Furthermore, I see that they do not automate slab generation but just the lattice matching, and the following DFT calculations, so the user still needs a way to generate the slabs.

[hongyi-zhao]

Thank you for your comments, @fyalcin, below are some of my further questions/thoughts based on the above points given by you:

It looks like they are just interested in adhesion energies, and I don't see anything in their code that can calculate surface energies

IMHO, adhesion energies are more complicated to compute than surface energies, and the former usually includes the latter as a substep. Am I right?

let alone handle arbitrary surfaces as we do here.

In real material systems, arbitrary surfaces may not always be meaningful. Just as we conduct structural searches to find possible stable structures and lattice matches to find reasonable heterojunctions, for surfaces, we should also need to determine whether they can exist stably.

So, while the implementation you mentioned above is indeed compelling in functionality, it would be even nice to have an algorithm that efficiently filters surfaces with the desired properties for a particular application/scenario.

Furthermore, I see that they do not automate slab generation but just the lattice matching, and the following DFT calculations, so the user still needs a way to generate the slabs.

I have not read the above paper in detail about the implementation of this aspect. However, the author's goal is to find heterojunctions with low energy that can exist stably. If the slab is not constructed, how can the corresponding DFT calculation be carried out in his paper?

[fyalcin]

IMHO, adhesion energies are more complicated to compute than surface energies, and the former usually includes the latter as a substep. Am I right?

I do have some experience in interfaces and I would just say that they are different, neither is more complicated than the other. The complexity stems from how generalized you want the workflow to be; whether you deal with elemental crystals or multi-component ones, whether or not you consider different terminations, how hands-off you want your workflow to be, and so on.

In real material systems, arbitrary surfaces may not always be meaningful. Just as we conduct structural searches to find possible stable structures and lattice matches to find reasonable heterojunctions, for surfaces, we should also need to determine whether they can exist stably.

So, while the implementation you mentioned above is indeed compelling in functionality, it would be even nice to have an algorithm that efficiently filters surfaces with the desired properties for a particular application/scenario.

We let the workflow do all the heavy lifting here for us. One can just start with a single MPid and set a maximum Miller index and the surface energies of all the symmetrically distinct terminations will be automatically calculated. If you have a multi-element crystal, for instance, you will most likely have multiple unique terminations for a given Miller index, and these are all taken care of. The data you collect can then be used to find the most stable termination, Wulff shape, and other properties one can extract from surface energies.

You can even first find the most stable termination with this package, as stable surfaces are more likely to form interfaces with greater adhesion, and then feed it into Hetero2D for adhesion energies or tribchem for the entire generalized stacking fault surface.

I have not read the above paper in detail about the implementation of this aspect. However, the author's goal is to find heterojunctions with low energy that can exist stably. If the slab is not constructed, how can the corresponding DFT calculation be carried out in his paper?

I was mistaken, they do provide a way to generate slabs with a given slab_params. However, their slab generation is not automated.

By the way, I have yet to update the README but if you are curious about how we handle arbitrary (bulk-terminated) surfaces, you might find this interesting.

[hongyi-zhao]

I do have some experience in interfaces and I would just say that they are different, neither is more complicated than the other.

It seems that the workflow/package mentioned in the above paper is still not publicly accessible now.

You can even first find the most stable termination with this package, as stable surfaces are more likely to form interfaces with greater adhesion, and then feed it into Hetero2D for adhesion energies or tribchem for the entire generalized stacking fault surface.

Wonderful idea.

By the way, I have yet to update the README but if you are curious about how we handle arbitrary (bulk-terminated) surfaces, you might find this interesting.

This is exactly the paper of this project.

[fyalcin]

It seems that the workflow/package mentioned in the above paper is still not publicly accessible now.

Sorry I was a bit vague, it is available as tribchem. You can find a link to the accompanying paper in the repo readme.

This is exactly the paper of this project.

Yes. I wasn't sure how you found this repo, through the paper or just by chance, and since the README doesn't mention the paper yet, I wanted to point it out. The paper and the SM have detailed explanations of how we solve some of the non-trivial issues with surface energy calculations of more complicated surfaces.

[hongyi-zhao]

Sorry I was a bit vague, it is available as tribchem. You can find a link to the accompanying paper in the repo readme.

My confusion stemmed from how the paper you mentioned earlier was described, as shown below:

I've tried to search triboflow package via Google and found nothing. So, I raised the question above.

I wasn't sure how you found this repo, through the paper or just by chance,

I've also forgotten the specific circumstances under which I initially discovered this repo. It might have been while I was trying to find the latest workflows related to surface and heterostructure studies based on high-throughput methods. Anyway, I found that if I tried searching for the pymatgen workflow package on Google Scholar, I could easily find this package:

Another possibility is that I first noticed this paper, among which has the following description on page 18:

To automate the generation of input files, we designed a workflow using aiida 121–123, pymatgen 124–126, pymatgen-analysis-defects 127, ASE 128, doped 129 and ShakeNBreak 75. This code is available from https://github.com/ireaml/defects_workflow.git. The datasets and trained models are available from the Zenodo repository with DOI 10.5281/zenodo.10514567.

Then, based on the above-mentioned packages/workflows, I explored further and eventually found the surfflow package.