Open pablosanjose opened 4 years ago
This will need to be revisited in view of the new onsite!
and hopping!
modifier concepts that were introduced with ParametricHamiltonian
and that replace fields.
In any case, I see little urgency in this functionality at the moment, so priority is low unless a compelling use case is brought forward.
Following #44, we should also refactor lazy Hamiltonians (defined on a non-materialized superlattice), so that it can contain fields, that have no reason to be part of a conventional Hamiltonian (since all fields are materialized already in the relevant matrices).
The
unitcell(::Hamiltonian,...)
codepath, that currently builds first a superlattice and then expands the Hamiltonian on it, could now create an intermediatesham::LazyHamiltonian = supercell(h,...)
containing the fields passed tounitcell
, that then gets materialized byunitcell(sham)
as a conventionalHamiltonian
, applying the fields on the way.That way we also reduce the current overlap between
hamiltonian.fields
and the possibility of creating aParametricHamiltonian
, which can be seen to fulfill similar goals. We should keepParametricHamiltonian
as a way to apply a model in place to any sites, and the fields mechanism as a way to transform existing hoppings and onsites, when growing a system or using it lazily.