zerothi / sisl

Electronic structure Python package for post analysis and large scale tight-binding DFT/NEGF calculations
https://zerothi.github.io/sisl
Mozilla Public License 2.0
180 stars 58 forks source link

Commonly used tight-binding models #279

Open zerothi opened 3 years ago

zerothi commented 3 years ago

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:

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.

tfrederiksen commented 3 years ago

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

pfebrer commented 3 years ago

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).

zerothi commented 3 years ago

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...

jonaslb commented 3 years ago

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?

zerothi commented 3 years ago

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 commented 3 years ago

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

zerothi commented 2 years ago

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. :)

pfebrer commented 2 years ago

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 :)

zerothi commented 2 years ago

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? :)