sisl icon indicating copy to clipboard operation
sisl copied to clipboard

Commonly used tight-binding models

Open zerothi opened this issue 3 years ago • 9 comments

Describe the feature A suite of tight-binding models typically used for testing and general purpose, lets first compose a list of useful tight-binding models:

  • [x] graphene, possible arguments should be t=-2.7, bond=1.42, also 3rd nearest neighbours
  • [ ] zgnr/agnr?
  • [ ] slater-koster methods for easier manipulation, see #140, this should be a wrapper around that solution
  • [ ] implement a generic category which incapsulates the neighbours and types to do post-processing based on this

My idea would be to place this in a sisl_toolbox since then it isn't really part of the core sisl team. It would encourage a broader addition of testing models if so desired.

zerothi avatar Oct 19 '20 12:10 zerothi

Sofia and I have been using quite a bit these models for sp2-carbon:

  • First-nearest neighbour model t = -2.7 eV,
  • Third-nearest neighbour model (t1, t2, t3) = -(2.7, 0.2, 0.18) eV, see PRB 81, 245402 (2010) (which, by the way, also provides parametrizations for nonorthogonal basis),
  • Different Slater-Koster parameterizations to handle out-of-plane couplings, eg. pz-pz interactions in stacked GNRs fitted to SIESTA-DFT as in our PRB 102, 035436 (2020).

tfrederiksen avatar Oct 19 '20 16:10 tfrederiksen

Hi Nick, there's not much I can add to the discussion because I have very little experience, sorry :)

But I think it would be great that in general you could pass custom first, second, third...(as many as you want) neighbour hoppings.

Also maybe some BondCategory might help to define strange things such as edges in ribbons (in bonds where not all atoms are AtomNeighbours(3), use this special hopping). I would say that the best way would be to first categorize all atoms and then use this categorizations for each bond (instead of calculating the atom categories for each bond individually).

pfebrer avatar Oct 19 '20 19:10 pfebrer

Thanks for your suggestions!

What should we name it?

from sisl_toolbox import hamiltonians
from sisl_toolbox import tb_models

?

Perhaps this would also go to be useful for dynamical matrices etc. Hence I want to have some kind of recognition of the Hamiltonian...

zerothi avatar Oct 20 '20 10:10 zerothi

You could namespace things as sisl_toolbox.tb_models.<geometry>.<type>.<example>? So that different types (H, dynmat, etc.) could share a particular geometry. And different implementations (eg. nearest neighbor vs 3rd nearest) would be in the same module together under that. But maybe it's too deep?

jonaslb avatar Oct 20 '20 12:10 jonaslb

A good idea.

I have also thought about a class that has all these things in one place. This let's it be more versatile, and it would have the required nested levels. So something like sisl_toolbox.models.<geometry> where these objects have methods for creating different higher level matrices.

zerothi avatar Oct 21 '20 06:10 zerothi

Reference for MX2 materials: https://arxiv.org/pdf/1305.6089.pdf

zerothi avatar Jun 28 '21 07:06 zerothi

For graphene this is now implemented, see sisl_toolbox.models.graphene.hamiltonian.ref["simple"] which is the basic TB model.

For now it is not as customizable, and I wish it had some other constructs as well. But I think this is ok to get in ASAP. :)

zerothi avatar Dec 08 '21 13:12 zerothi

I like the sp2 constructor in the Hubbard code. Perhaps it (or something like it) could be available in sisl and return a function that you can pass to Hamiltonian.construct(). Something like:

geom = sisl.geom.graphene_nanoribbon()
H = sisl.Hamiltonian(geom)

H.construct(
    sisl.sp2(...parameters)
)

I'm proposing this because it would be more "consistent" with the way constructing a hamiltonian works now in sisl, but it could of course just return the hamiltonian, and in that way it could also add orbitals to the basis to plot wavefunctions I guess.

Anyway, the main point is that a generic sp2 model creator seems useful, and they already developed it :)

pfebrer avatar Dec 09 '21 10:12 pfebrer

I like the sp2 constructor in the Hubbard code. Perhaps it (or something like it) could be available in sisl and return a function that you can pass to Hamiltonian.construct(). Something like:

geom = sisl.geom.graphene_nanoribbon()
H = sisl.Hamiltonian(geom)

H.construct(
    sisl.sp2(...parameters)
)

I'm proposing this because it would be more "consistent" with the way constructing a hamiltonian works now in sisl, but it could of course just return the hamiltonian, and in that way it could also add orbitals to the basis to plot wavefunctions I guess.

Anyway, the main point is that a generic sp2 model creator seems useful, and they already developed it :)

That is probably a good idea for an upper level constructor. I would suspect that users want the minimal code for getting simple things in return, so your first 2 lines of codes I would like to pack into the functionality. And then that complicates it a bit more, an idea how to make this functional? :)

zerothi avatar Dec 09 '21 14:12 zerothi