Limit on number of hoppings about pybinding HOT 3 CLOSED

Depending on your situation, there are two options:

1. Reorganize the Lattice definition to work around the limit.
2. Or change a variable in the C++ source code to increase the available memory.

Exactly how to apply option 1 would depend on the unit cell you're building. I'm guessing it's either a large supercell or a model with a large number of orbitals per lattice site. The hopping limit is actually a limit of the number of unique hopping energies that can be saved. In the case of a supercell, this means that you can work around the limit by creating the supercell with a small set of constant energy hoppings and then applying any position dependent behavior via @pb.hopping_energy_modifier. But again, this depends on what kind of model you're building, so let me know if you need something more specific.

For option 2, you could just go into the C++ source and change this line v0.8.1-Lattice.hpp#L11 from std::int8_t to std::int16_t which would bump the limit up to ~32000 unique hopping energies. You would need to recompile the package. The advanced installation guide has the instructions for that here. I recommend that you also use git checkout v0.8.1 so that you apply the change to the latest stable version rather than the master branch (development is well under way for v0.9 on master).

Let me know if need any help either way. I'd also be curious to know what kind of model hit the limit, if you can share more details. Version v0.9 should resolve the limit for multi-orbital models, but perhaps I should take a look at lifting the supercell limits sooner rather than later.

from pybinding.

Thanks very much.

The tight binding model is for a single layer of InSe, with 4 atoms in the unit cell (hexagonal lattice), each atom has 4 orbitals s, px, py, pz and I consider hopping to nearest and next-nearest neighbours between In and Se, In and In, and Se and Se. The total number of parameters including on-site energies is 37.

So I will try to increase the memory for that variable.

from pybinding.

Yes, that would definitely go over the limit due to 4 orbitals per site + next-nearest. The memory increase workaround should do well until v0.9 brings better multi-orbital support.

from pybinding.