Reading wannier Hamiltonian with out '_centres.xyz' present

[nils-wittemeier]

When trying to read the Hamiltonian from <>_tb.dat or <>_hr.dat without <>_centeres.xyz present, we try to read the geometry from the Wannier input, which returns a geometry with the 'correct' atoms and positions. However, for the Hamiltonian, this geometry is not suited (the number of wannier functions in general is different from the number of atoms).

To fix this problem I would suggest, implementing the following procedure:

In sisl.io.wannier90.seedname.read_hamiltonian we explicitly call read_geometry with order=['centers']. Should this call fail, we obtain the number of Wannier functions (n_wann) from the <>.win file or as a fallback from the Hamiltonian file and create a fake geometry with n_wann orbitals all centered at the origin.

This could be later improved by using the initial projections as the locations of the orbitals.

@zerothi, please let me know if this makes sense to you. If so, I'll create a PR for this.

[zerothi]

I agree, this is sub-optimal.

Indeed there should be a stricter understanding of what is read.

It seems to me that it would be a bit more strict:

1. read_geometry should try and read the centres, and should never read stuff from the *.win file since one typically needs the centres. One should be able (via order argument) to request the win content). This could follow the order parameter used in Optimize nsc after reading Hamiltonian from wann90 output #697
2. Then we wouldn't need to change things in the hamiltonian read?
3. I don't know about the implications, but it seems to me that if we think the centres are located at input coordinates we could be wrong, and here it would result in problems...

[zerothi]

Or, should we add a new Sile type that reads the Hamiltonian, which then forcefully reads the centres?.

It is a bit weird to use the input file and value returns in the same file... It can get error prone.

[nils-wittemeier]

I guess, the best approach would be to split the Sile. Would we create separate Siles for the <>_tb.dat and <>_hr.dat files?

Using the order argument for the geometry reading makes sense to me to determine which file to read.

However, to me, there is some ambiguity in what is read. Maybe we should consider having a read_geometry function to read the geometry of the crystal structure and read_wanniercentres , or similar, to read Wannier centers (as a geometry). I think both functionalities can be useful, but to different things, so they should be properly separated.

[zerothi]

It seems to me that the best approach would be to split the siles. Having an read_wanniercentres is a bit unintuitive since it really is the electronic structure geometry (although its coherence with a Geometry is rather weak).

Perhaps we could try with a sile that parses the _tb.dat file, then that can fallback to the _hr.dat file if needed, it seems like _hr.dat will be made obsolete. What do you think here?

[nils-wittemeier]

That sounds reasonable. A few questions:

1. Should the read_geometry functionality will remain in the original sile?
2. How should we handle the case if the _centres.xyz is absent? When reading from _tb.dat we have the lattice vectors and number of orbital in the file itself and can create a dummy geometry. For the _hr.dat file, we don't have access to the lattice vectors only, the number of orbitals.

P.S. What makes you think that the _hr.dat file will be made obsolete?

[zerothi]

It just seemed like the _tb.dat contains the necessary information, and _hr.dat is obsolete due to the extra isc notation (which is duplicated no**2-1 times. But I could easily be wrong...

So having two files with the same information is something that calls for obsoleting stuff, thats it.