DFTK.jl icon indicating copy to clipboard operation
DFTK.jl copied to clipboard

Special-case entropy

Open antoine-levitt opened this issue 4 years ago • 2 comments
trafficstars

Our entropy term is weird. It's not really a function of the input density matrix (psi, occ), it also depends on the eigenvalues (and there's no one-to-one mapping between them in the case of Methfessel-Paxton smearing). We should probably just take it out of the regular terms and special-case it. That would allow the input interface to the terms to be more consistent, ie only take as input psi, occ, rho. These we could possibly put into a struct or something

antoine-levitt avatar Jul 19 '21 10:07 antoine-levitt

What you're thinking is a struct giving like a (partial) representation of the density matrix? That sounds reasonable to me.

mfherbst avatar Jul 23 '21 19:07 mfherbst

Yeah. It does sound reasonable and is something I've wanted to do for a while.

  • What to call it. ElectronicState?
  • What to put inside. Psi, occ and rho and that's it?
  • It does introduce an annoying extra layer of indirection, i.e. scfres.state.psi, scfres.state.rho, etc. Or we could have a struct for scfres and overload getproperty to forward psi and rho directly
  • It would have a constructor ElectronicState(basis, psi, occ) but it also needs to have a ElectronicState(basis, psi, occ, rho) with rho not built from the psi or the occ, because we need that for SCF. So it kind of destroys the consistency of the struct. But then again that consistency is already lost when we call energy_hamiltonian with a rho not consistent with the psi...

antoine-levitt avatar Jul 24 '21 11:07 antoine-levitt