Ill-defined behavior of stack when using odd num_spin_orbitals

[kevinsung]

What is the expected enhancement?

AngularMomentum is currently initialized by specifying the number of spin orbitals. This is confusing because it doesn't make sense to have an odd number of spin orbitals, and passing an odd number seems to give the same operator as the next lowest even number:

from qiskit_nature.second_q.properties import AngularMomentum

op1 = AngularMomentum(2).second_q_ops()['AngularMomentum']
op2 = AngularMomentum(3).second_q_ops()['AngularMomentum']
print(op1.equiv(op2))

True

I think it should take the number of spatial orbitals as input instead.

[mrossinek]

This was a design flaw of the properties framework. This will be addressed as part of 0.5. It is blocked by:

• merging of the SparseLabelOp (Add SparseLabelOp base class #731)
• rewrite of the FermionicOp as a subclass of the SparseLabelOp (in progress by myself, PR coming soon)
• merging of the PolynomialTensor (Add PolynomialTensor class #756)
• implementing Implement FermionicOp.from_polynomial_tensor #666 (will be part of the aforementioned PR which I am working on)

Once all of the above is done, all of the existing classes in qiskit_nature.second_q.properties which build out a FermionicOp will be revisited and improved 👍

[mrossinek]

This issue is actually more general with respect to the usage of odd values for num_spin_orbitals against which no guards are in place. A proper solution would be to consistently switch over to num_spatial_orbitals, instead 👍