Users can't map wavefunc coeffs to the corresponding configuration

[caleb-johnson]

Environment

All environments

What is happening and why is it wrong?

The wavefunction coefficients returned from solve_fermion are stored in an MxN matrix, where M is the number of unique alpha determinants and N is the number of unique beta determinants. The rows and columns are associated with the sorted (ascending) determinants.

Since users pass in a bitstring matrix, they have no way of knowing to what configuration each amplitude is associated (Keep in mind the output configurations don't even have to be present in the set of input configurations.)

Any suggestions?

The user should be returned a mapping from configuration to amplitude. The most straightforward thing to do would be to return a dict[int, float] mapping the full spin configuration to the associated amplitude.

We could also return a tuple as shown here.

[kevinsung]

Actually, the wavefunction coefficients are returned as a PySCF SCIvector object, which does have the configurations stored in the _strs attribute. However, this is an issue for qiskit-addon-dice-solver.

[caleb-johnson]

Actually, the wavefunction coefficients are returned as a PySCF SCIvector object, which does have the configurations stored in the _strs attribute. However, this is an issue for qiskit-addon-dice-solver.

As discussed offline, I'd like users to be able to inspect the coefficients and CI strings without needing to access a private field. Our source will still need to access that field to unpack the strings, which isn't great. We can assert (or error out) that sci_vec._strs is populated and well-formed as it is returned from PySCF, since that is an undocumented assumption we are making about that field (I think it's a safe assumption).

I will definitely cast the SCIVector to a vanilla np.ndarray after unpacking the _strs field to avoid storing redundant CI string data. I am debating whether the sci coefficients output from solve_fermion should be a data class containing the coeffs and the strings or a tuple as suggested above. Maybe a named tuple?

[caleb-johnson]

I think I favor the name SCIState for this dataclass