Handling of bands in pair
There are several possible pitfalls in handling band index lists in pair.py.
KPointPair is constructed with valence and conduction band ranges https://gitlab.com/gpaw/gpaw/-/blob/master/gpaw/response/bse.py?ref_type=heads#L362
In KPoint storage, the bands are then truncated to match these ranges https://gitlab.com/gpaw/gpaw/-/blob/master/gpaw/response/pair.py?ref_type=heads#L97
get_transition_energies
and get_occupation_differences
methods of KPointPair then take as an input absolute list of indices
https://gitlab.com/gpaw/gpaw/-/blob/master/gpaw/response/pair.py?ref_type=heads#L41
Thus, user must again create ranges from those initial and final bands to call these methods, thus what is actually returned in almost all of the cases is the full cropped eps/band/f array. This is slightly counter intuitive.
In addition, there already are several consequences of this structure:
-
m_m is ignored in some cases at pair.py (however, user expected all bands anyway as specified by the get_pair method, so this works).
get_pair_density
of pair ignores m_m, https://gitlab.com/gpaw/gpaw/-/blob/master/gpaw/response/pair.py?ref_type=heads#L176 and calls calculate_pair_density where it takes all of the truncated bands. Thusget_pair_density
only works as expected, if m_m is exactly the original band range given to get_pair. https://gitlab.com/gpaw/gpaw/-/blob/master/gpaw/response/pair.py?ref_type=heads#L239 -
User can request bands below n1, which turn now into negative indices, and the numpy array is wrapped around returning invalid indices. https://gitlab.com/gpaw/gpaw/-/blob/master/gpaw/response/pair.py?ref_type=heads#L41
However, there appears not to be any known bugs due to this behavior.