Closed AlexandreFoley closed 1 year ago
Had you seen this https://qiskit.org/ecosystem/nature/stubs/qiskit_nature.second_q.operators.FermionicOp.index_order.html It was done as part of #902 which addressed the #901 issue you referred to above. #902 has some comment in there as regards the choice things that way.
It's of little help when working with generic SparseLabelOp. simplify is apart of the generic interface, but not normal_order, nor index_order. At best, those are workaround for FermionicOp simplify failing to simplify the fermionic operator.
With the current development version of Qiskit Nature F
has only 6 terms from the beginning (and never 106).
Regardless of that, as Steve also pointed out earlier, this behavior is intentional as explained here:
https://github.com/qiskit-community/qiskit-nature/blob/eb30b6b0e8b042a1f431a1ce7a633856b8b5bcf4/qiskit_nature/second_q/operators/fermionic_op.py#L437-L444
Arguably, we should add this note to the docstring of the FermionicOp.simplify
method, too.
Environment
What is happening?
Calling simplify on a FermionicOp doesn't yield a fully simplified representation of the operator. Calling normal order first seems to be a work around for this issue, but it makes simplifying SparseLabelOp in a generic manner impossible.
Simplify for Fermionic op should likely make use of normal ordering to perform simplification. The current implementation doesn't work. This is similar to issue #901, but it's not that simplify is not agressive enough, but that it fail entirely to simplify the fermionic operator.
How can we reproduce the issue?
What should happen?
simplify should manage to reduce the number of label in F as much or more than normal_order
Any suggestions?
aplying normal ordering could be part of simplify's implementation.