sisl
sisl copied to clipboard
Commonly used tight-binding models
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.
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).
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).
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...
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?
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.
Reference for MX2 materials: https://arxiv.org/pdf/1305.6089.pdf
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. :)
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 :)
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 toHamiltonian.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? :)