Migrated from Enterprise Github.
Creator: @mrossinek

All bosonic drivers need to be adapted to produce a SecondQuantizedSumOp rather than a QMolecule. Be sure to also take a look at #14 for examples of the fermionic driver.

• GaussianForcesDriver

We also need to figure out a good place for the following classes:

• WatsonHamiltonian
• BosonicBasis
  • HarmonicBasis

Migrated from Enterprise Github.
Creator: @mrossinek

Since the latest release of Qiskit Aqua we have the FermionicTransformation (and alike) classes which can be used to quickly map from a problem description (i.e. a driver) to a qubit operator.
With the refactored input flow we want to be able to do something similar but we will call it slightly differently.

As an example I here propose a ProblemTranslation. We need to do the following things for it:

• design its general interface: ProblemTranslation
  • likely it will map from a Driver to a PauliSumOp
  • it will need to be able to apply mappings and transformations
• add basic implementations for the cases:
  • fermionic
  • bosonic
  • (optionally:) spin [possibly related to Simon and Giulia's lattice models]

Migrated from Enterprise Github.
Creator: @mrossinek

• implement the to_opflow() method in both, primitives.FermionicOperator and FermionicSumOp
• unittest all methods

Migrated from Enterprise Github.
Creator: @mrossinek

• implement the to_opflow() methods for both, primitives.SpinOperator and SpinSumOp
• unittest all methods

In looking at the setters/getters in MES factories, during the gradient addition qiskit-community/qiskit-aqua#1421 , I notice the original getter/setters for initial_point, expectation, optimizer, that default to None in factory constructor, do not show in typehint that None is a valid value to set these too, via setter, or one would expect to have None back from getter, i.e. are Optional as has now been done for gradient. I think it should be valid to set to None so you go can back to default. Either way the getter needs to show Optional.

Information

• Qiskit Aqua version: qiskit-master
• Python version: 3.8
• Operating system: Ubuntu

What is the current behavior?

same_spin_doubles = True in UCCSD variational form does not work correctly, when only beta same spin double excitations are required.

Steps to reproduce the problem

I faced this problem with triplet O2 molecule. For alpha orbitals there is only one unoccupied spin-orbital, while for beta there are three. I'm expecting to have same spin double excitations only for beta orbitals. However, there are no such excitations when same_spin_doubles = True.

What is the expected behavior?

Suggested solutions

Change condition here. When this condition is False due to alpha orbitals, beta сondition is omitted. My solution is:

        if same_spin_doubles:
            if len(active_occ_list_alpha) > 1 and len(active_unocc_list_alpha) > 1:
                for i, occ_alpha in enumerate(active_occ_list_alpha[:-1]):
                    for j, unocc_alpha in enumerate(active_unocc_list_alpha[:-1]):
                        for occ_alpha_1 in active_occ_list_alpha[i + 1:]:
                            for unocc_alpha_1 in active_unocc_list_alpha[j + 1:]:
                                double_excitations.append([occ_alpha, unocc_alpha,
                                                           occ_alpha_1, unocc_alpha_1])

            up_active_occ_list = active_occ_list_beta
            up_active_unocc_list = active_unocc_list_beta

            if len(active_occ_list_beta) > 1 and len(active_unocc_list_beta) > 1:        
                for i, occ_beta in enumerate(up_active_occ_list[:-1]):
                    for j, unocc_beta in enumerate(up_active_unocc_list[:-1]):
                        for occ_beta_1 in up_active_occ_list[i + 1:]:
                            for unocc_beta_1 in up_active_unocc_list[j + 1:]:
                                double_excitations.append([occ_beta, unocc_beta,
                                                           occ_beta_1, unocc_beta_1])

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected enhancement?

In the old Qiskit Aqua, all runtime specific information generated by a driver were stored in the QMolecule class, which will not be moved to Qiskit Nature.
However, we are still in need of a container for all of this information and it should not only be stored centrally by the problems-wrappers because these wrappers should really only compose the functionality of other pluggables. In this way, the user also has the flexibility and power to use this information outside of a problems-wrapper.

Thus:

• We need to adapt the drivers to produce a DriverResult which should store all runtime-relevant information generated by a driver.
• This should in large replace all of this information from the old QMolecule class.
• This class should provide a get_second_quantized_op() method which is capable of converting the integrals generated by a driver into a SecondQuantizedOp.
• In order for the above to work we need to mirror the fermionic and bosonic differentiation of the drivers. Thus, we need: BaseDriverResult, FermionicDriverResult and BosonicDriverResult classes.

Points open for discussion:

• it is not yet clear where we will add the WatsonHamiltonian and BosonicBasis classes into Qiskit Nature. Since these are mainly auxiliary objects for the bosonic case, I think these are coupled to the BosonicDriver implementations that we have.
• I am open for suggestions on how to handle this specific case.

Migrated from Enterprise Github.
Creator: @ikkoham

Summary

Jupyter note.
https://gist.github.com/ikkoham/3526cbb006af17cb5c97315467e31190

CHC is currently a VariationalForm. This should be refactored over to circuit/library as a BluePrint circuit

What is the expected feature?

Add the FreezeCoreTransformer.

• actual implementation
• unittests
• documentation

What is the expected feature?

Add the ActiveSpaceTransformer.

• actual implementation
• unittests
• documentation

(I will set this to high priority because we need a first transformer working, in order to perform some initial testing. I will hopefully have a PR for this ready by the mid of next week.)

Migrated from Enterprise Github.
Creator: @mrossinek

The current BosonicOp is a mere copy of the FermionicOp with a search-and-replace of fermionic for bosonic. The actual mathematics of the implementation need to adapted.

• adapt the mathematics of the BosonicOp
• unittest all methods

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the LogarithmicMapper.
This issue breaks-out of #18 and can be used to assign and discuss related topics.

• Implementation
• Unittest
• Documentation

Migrated from Enterprise Github.
Creator: @mrossinek

• unittest all methods

• unify the SecondQuantizedOp as much as possible with the other classes

• make the SecondQuantizedSumOp implement the SumOp interface

Migrated from Enterprise Github.
Creator: @mrossinek

Let's use this issue for general discussions which do not fit into a specific issue (yet).
To get this started, here is the updated overview of qiskit_nature.

EDIT: I uncommented the oudated UML diagram. Please see the last comment of this issue for the most up-to-date version.

What is the expected enhancement?

#60 added the QubitConverter which should be integrated into the algorithm stack.
The rationale is the following:

• In the past we had multiple keyword arguments on the FermionicTransformation (and elsewhere) which configured the qubit_mapping and z2_symmetries, etc.
• Now, we replaced these transformations with the problems module in which we only add problem-describing parameters.
• Since the aforementioned keywords deal with "how the algorithm solves the problem", these should go into the algorithms stack.
• Thus, we need to replace the legacy transformation argument in the algorithms with a converter argument.

What is the expected feature?

Implement the VibronicStructureProblem class. (the name is a WIP)
It may be located in the qiskit_nature.problems.second_quantization.vibrational module. (Or do we want this to be in qiskit_nature.second_quantization.molecular?)

An important aspect to consider here, is that this implementation is responsible for the correct construction of the SecondQuantizedOp. This means, that it needs to handle the differentiation of modes and modals and construct the BosonicOp accordingly.

Information

• Qiskit Aqua version: lastest
• Python version:
• Operating system:

What is the current behavior?

for example:

driver = PySCFDriver(molecule = 'happy holidays', unit=UnitsType.ANGSTROM, basis='happy holidays')

does not generate an error when the object is built. The unit kwarg does look for an enum, but that is it. This leads to hard to read errors down the line:

e.g. the above gives:

AttributeError: 'str' object has no attribute 'geometry'

or

driver = PySCFDriver(molecule = molecule, unit=UnitsType.ANGSTROM, basis='happy holidays')

gives:

QiskitChemistryError: 'Failed electronic structure computation'

Steps to reproduce the problem

What is the expected behavior?

Suggested solutions

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the DirectMapper.
This issue breaks-out of #18 and can be used to assign and discuss related topics.

• Implementation
• Unittest
• Documentation

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the BravyiKitaevSuperFastMapper.
This issue breaks-out of #18 and can be used to assign and discuss BKSF-related topics.

• Implementation
• Unittest
• Documentation

A PR was started in qiskit-aqua qiskit-community/qiskit-aqua#1483 but the work should be moved/re-done here.

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the LinearMapper.
This issue breaks-out of #18 and can be used to assign and discuss related topics.

• Implementation
• Unittest
• Documentation

What is the expected enhancement?

UCCSD needs to be refactored for several reasons:

• it is incompatible with the VQE implementation provided by Qiskit Terra
• it uses the (soon-to-be-removed) FermionicOperator class
• it uses the legacy WeightedPauliOperator

The following requirements should be met by the new implementation:

• it should derive BlueprintCircuit and, thus, be compatible with Terra
• the hopping operator factory logic should be moved to an external place as it can also be of use elsewhere (currently FermionicTransformation actually uses the logic inside of UCCSD)
• it should make use of the new FermionicOp and opflow operators
• ideally, the hopping operator factory should be generalized to work for any kind of exctitation (S, D, T, Q, ...)
• ideally, we would have a UCC class in which the user can freely specify the types of excitations he would like to have
• (we may provide ease-of-use subclasses like UCCSD, UCCD, etc.)

Once UCCSD has been refactored we should also be able to replace all qiskit.aqua imports with their new counterparts. Thus, the critical status of this issue.

Information

• Qiskit Aqua version: 0.8.1
• Python version: 3.6.8
• Operating system: Ubuntu

What is the current behavior?

For H2 molecule QEOM excited state energies differ running with Statevector and Qasm simulators.

Steps to reproduce the problem

Please, run the gist

What is the expected behavior?

Close excited state energies

Suggested solutions

Seems like the problem is somewhere in eval() method, but I'm not sure about that.

Migrated from Enterprise Github.
Creator: @ikkoham

Summary

What is the expected feature?

Implement the MolecularProblem class.
It should be located in the qiskit_nature.problems.second_quantization.molecular module.

A non-exhaustive list of tasks is:

• port the old FermionicTransformation to the MolecularProblem
• move all mapping logic out of the problem and into the GroundStateCalculation interface
• add logic for handling transformers
• add logic for constructing a list of SecondQuantizedOp out of the QMolecule as generated by the driver
• unittest all methods

What is the expected feature?

Add the ParticleHoleTransformer.

• actual implementation
• unittests
• documentation

The interface needs changing since the way mappings are now specified is different. Maybe add some state mapping to the mappers in order to allow the HF state to be mapped accordingly. Maybe like the UCCSD proposal this can then take QubitConvertor since it needs also information related to any symmetry reduction of the main (Hamiltonian) operator of the problem.

Migrated from Enterprise Github.
Creator: @mrossinek

The state of the SecondQuantizedSumOp-Transformations is the following:

• Implementation
  • SeniorityZeroTransformation
  • FreezeCoreTransformation
  • ActiveSpaceTransformation
  • ParticleHoleTransformation
  • TranscorrelatedTransformation
• Unittests
  • SeniorityZeroTransformation
  • FreezeCoreTransformation
  • ActiveSpaceTransformation
  • ParticleHoleTransformation
  • TranscorrelatedTransformation

Note: this issue may be broken down into several issues as work starts to progress.

Migrated from Enterprise Github.
Creator: @mrossinek

All fermionic drivers need to be adapted to produce a SecondQuantizedSumOp rather than a QMolecule. As a good starting point, the following may be helpful to transform what is currently stored in a QMolecule into a FermionicSumOp:

base_ops = []

one_body_ints = qmol.one_body_integrals
for idx in itertools.product(range(len(one_body_ints)), repeat=2):
    coeff = one_body_ints[idx]
    if not coeff:
        continue
    label = ['I'] * len(one_body_ints)
    base_op = FermionicOperator(label, coeff=coeff)
    for i, op in [(idx[0], '+'), (idx[1], '-')]:
        label_i = label.copy()
        label_i[i] = op
        base_op *= FermionicOperator(''.join(label_i))
    base_ops.append(base_op)

two_body_ints = qmol.two_body_integrals
for idx in itertools.product(range(len(two_body_ints)), repeat=4):
    coeff = two_body_ints[idx]
    if not coeff:
        continue
    label = ['I'] * len(two_body_ints)
    base_op = FermionicOperator(label, coeff=coeff)
    # mind the chemists' notation of the two-electron integrals!
    for i, op in [(idx[0], '+'), (idx[2], '+'), (idx[3], '-'), (idx[1], '-')]:
        label_i = label.copy()
        label_i[i] = op
        base_op *= FermionicOperator(''.join(label_i))
    base_ops.append(base_op)

fer_op = FermionicSumOp(base_ops)

• CP2KDriver
• FCIDumpDriver
• GaussianDriver
• HDF5Driver
• Psi4Driver
• PyQuanteDriver
• PySCFDriver

What is the expected feature?

Implement the LatticeModel class. (we may want to call this a LatticeProblem)
It should be located in the qiskit_nature.problems.second_quantization.lattice module.

An important aspect to consider here, is that this implementation is responsible for the correct construction of the SecondQuantizedOp. This means, that it needs to know how to construct (what used to be a SpinOp in the original design considerations) in terms of a BosonicOp.

Migrated from Enterprise Github.
Creator: @mrossinek

The state of the QubitMappers is the following:

• Implementation
  • JordanWignerMapper (fermionic)
  • ParityMapper (fermionic)
  • BravyiKitaevMapper (fermionic)
  • BravyiKitaevSuperFastMapper (fermionic)
  • DirectMapper (bosonic)
  • LinearMapper (spin)
  • LogarithmicMapper (spin)
• Unittests
  • JordanWignerMapper (fermionic)
  • ParityMapper (fermionic)
  • BravyiKitaevMapper (fermionic)
  • BravyiKitaevSuperFastMapper (fermionic)
  • DirectMapper (bosonic)
  • LinearMapper (spin)
  • LogarithmicMapper (spin)

Note: this issue may be broken down into several issues as work starts to progress.

What is the expected enhancement?

@Cryoris brought up the very good suggestion, that we should make an effort to disambiguate the commonly used num_orbitals keyword argument. This is used throughout a large part of the stack with either of the two meanings:

1. number of molecular orbitals
2. number of spin orbitals

Before releasing Nature, we should attempt an effort to clearly disambiguate these cases by replacing the argument with (e.g.)

1. num_molecular_orbitals
2. num_spin_orbitals

This will clearly tell the user what is expected without having to look into the docstring of each class.

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the ParityMapper.
This issue breaks-out of #18 and can be used to assign and discuss Parity-related topics.

• Implementation
• Unittest
• Documentation

Migrated from Enterprise Github.
Creator: @mrossinek

• extract common functionality into the ParticleOperator

  • This will probably affect things like __sub__, __rmul__, __neg__, __pow__, __ne__ because all of these can link to their counterpart

• extract common functionality into the SumOp (similar to the above)

What is the expected enhancement?

I already mentioned qiskit_nature.mp2info here because it is still coupled to the old UCCSD implementation. Do we need this for the release next week?

@pbark @woodsp-ibm

The current function 'particle_hole_transformation' (in qiskit-aqua/qiskit/chemistry/particle_hole.py) doesn't respect imaginary parts in a Hamiltonian given as an input argument. Hamiltonian with complex amplitudes should be correctly supported.

Re-organize unit tests such that instead of a flat structure they are in a folder structure akin to the code.

We may want to adopt the same structure as Terra under test where they have different folders with the units tests under a python folder.

What is the expected improvement?

To add an implementation of the HF and DFT embedding schemes proposed in this paper: https://arxiv.org/abs/2009.01872.

The aforementioned paper provides an algorithm which allows embedding a quantum computing calculation into a DFT calculation. We already have a basic implementation based on the development version of Qiskit which we will open a PR for once the paper is published.

In the meantime, we can use this issue to discuss some of the implementation aspects which involve the paper. At this time, I can say that the implementation can be separated into 3 logically separate blocks. I will outline the concepts of each of these below.

1. HF Embedding

The first block is a simple extension of the QMolecule class. It adds a new static method called active_space_reduction which can be used to achieve a proper HF embedding through calculating the inactive Fock operator which is in turn used instead of the 1-electron integrals in all further calculations.
This allows the specification of an active space to which the quantum calculation is being restricted.

Some more notes:

• I have exposed the same functionality in the Hamiltonian class (similarly to how freeze_core is exposed)
• the active space can even be selected manually (i.e. it is not limited to be a symmetric selection around the Fermi level)
• unittests are also in place

2. PySCFDriver Refactoring

In order to prepare the final goal (which is the DFT Embedding) we need to refactor the PySCFDriver (which is for now the only supported driver). Since the PyQuanteDriver has common aspects with the PySCFDriver I have extended the refactoring to it as well, where applicable.
This refactoring includes the following aspects:

• deprecation of HFMethodType in favor of pyscfd.MethodType and pyquantd.MethodType
• deprecation of hf_method in favor of method (in both, PySCFDriver and PyQuanteDriver)
• DFT support in both drivers
• support for disabling the dipole integral computation in PySCFDriver
• support for QMolecule construction based on a PySCF chkfile

3. DFT Embedding

Since this DFT Embedding poses a fully fledged application of Qiskit within the chemistry submodule, I have implemented this algorithm as a new class in the qiskit.chemistry.applications module. The implementation is currently limited to be used with the PySCFDriver but supports full configuration in most (I dare not say, all) other aspects. Further driver support is a WIP.
After the successful integration of the previous two paragraphs, this change should essentially only involve the addition of the new class and corresponding unittests.

If you would like to learn more about the algorithm please check out the paper. To highlight the most important aspects of the DFT embedding scheme I have included its technical visualization below.

Information

• Qiskit Aqua version: latest
• Python version:
• Operating system:

What is the current behavior?

In going through this tutorial here: https://qiskit.org/documentation/tutorials/chemistry/03_ground_state_solvers.html it is clear that the VQE solver does not actually use the input variational form. For example, I can do

num_qubits = 1
tl_circuit = TwoLocal(num_qubits, ['h', 'ry'], 'cz',
                      entanglement='linear', reps=2, parameter_prefix = 'th')
callback = Callback()

#backend = Simulators.aer_manhattan_simulator
backend = Aer.get_backend('qasm_simulator')
another_solver = VQE(var_form = tl_circuit, optimizer=SPSA(maxiter=250), callback=callback,
                     quantum_instance = QuantumInstance(backend, shots=2048))

tl_circuit.draw()

which yields:

     ┌───┐┌───────────┐┌───┐┌───────────┐┌───┐┌───────────┐
q_0: ┤ H ├┤ RY(th[0]) ├┤ H ├┤ RY(th[1]) ├┤ H ├┤ RY(th[2]) ├
     └───┘└───────────┘└───┘└───────────┘└───┘└───────────┘

However this is not what is actually used. Calling

calc = GroundStateEigensolver(transformation, another_solver)
res = calc.solve(driver)

works just fine, and the callback function gives the parameter vector for a 4 qubit variational form.

Now my guess is that this is because it needs a 4Q circuit, but then the solver should raise an exception rather then implicitly recast things.

Steps to reproduce the problem

What is the expected behavior?

Suggested solutions

A first pass was merged with Z2Symmetry support, this should be added to the function, along with the two qubit reduction based on the mappers.

If we provide a mechanism to map state from its fermionic to qubit equivalent, as we need for HartreeFock, then this should be added and exposed on the Qubit convertor as a capability too based on the function of state mapping being added to and provided by the mappers. So they would map state as well as operators to the qubit form.

Information

• Qiskit Aqua version: qiskit-master
• Python version: 0.3.7
• Operating system: Ubuntu

What is the current behavior?

I investigated my issue #52, where matrix elements of Q matrix in qEOM were completely incorrect. It turns out that using evaluate_operators() from GroundStateEigensolver produces incorrect expectation values when running with qasm simulator.

Steps to reproduce the problem

See #52.
Also there is a more simple case: after running VQE-UCCSD calculation I get optimal parameters for the circuit. If I use evaluate_operators() to get the energy on the optimized circuit, the value is different from the one which I got by VQE procedure.

What is the expected behavior?

Expectation value of the operator should not strongly depend on the simulator.

Suggested solutions

I copied the code of construct_expectation() from VQE and it helped me to get results equivalent to the statevector ones.

What is the expected enhancement?

There is no way to tell from the documentation what values are supported for the basis kwarg in the drivers. Only PyQuanteDriver gives the values, the rest just say basis (str) – Basis set.

For reference see: https://qiskit.org/documentation/apidoc/qiskit.chemistry.drivers.html

What is the expected feature?

Add the SeniorityZeroTransformer.

• actual implementation
• unittests
• documentation

See qiskit-community/qiskit-aqua#703 which was a draft PR to added a Hamiltonian Variational Form (or Trotterized Adiabatic State Preparation, TASP) .

What might be nice to have is a base class for an ansatz that is built from evolving operators. Maybe this base class ends up in qiskit circuit library. It could potentially be used as base for QAOA ansatz, UCCSD etc. And also to provide an ansatz as per the linked draft PR.

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the JordanWignerMapper.
This issue breaks-out of #18 and can be used to assign and discuss JW-related topics.

• Implementation
• Unittest
• Documentation

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected enhancement?

Naming

In the remainder of Qiskit we are consistently using verbs for class names, rather than nouns.
Thus, we should follow that approach and rename the classes and modules like:

• Mapping -> Mapper
• Transformation -> Transformer
  etc.

Location

Currently, we plan a differentiation between first and second quantization in the problems, operator and transformer modules. However, the mappers also require this differentiation because (at least the currently existing ones) only work in that regime. Thus, we should move all current mappers:

• qiskit_nature.mappers.* -> qiskit_nature.mappers.second_quantization

What is the expected enhancement?

The legacy UCCSD implementation had a method_doubles="succ_full" option which is not yet implemented in Qiskit Nature.
This option is a variant of the (now named) SUCCD option which also includes symmetrically mirrored double excitations, however, using the same parameter as the symmetric counter part (as also noted here).

The original implementation in Qiskit Aqua came from the work of this paper in which sections II.E.2 and appendix E provide more in-depth information.
The following Qiskit Nature snippet shows the current state of the SUCCD ansatz for the example discussed the aforementioned paper's appendix:

from qiskit_nature.circuit.library.ansatzes import SUCCD
from qiskit_nature.converters.second_quantization import QubitConverter
from qiskit_nature.mappers.second_quantization import JordanWignerMapper

converter = QubitConverter(JordanWignerMapper())
ansatz = SUCCD(converter, (1, 1), 6)

print(ansatz.decompose().draw())
print(ansatz.excitation_list)

which outputs:

     ┌─────────────────────────────────────────────────────────────────────────────────────────────┐»
q_0: ┤0                                                                                            ├»
     │                                                                                             │»
q_1: ┤1                                                                                            ├»
     │                                                                                             │»
q_2: ┤2                                                                                            ├»
     │  exp(-it (IYYIXY + IXXIXY + IXYIYY + IYXIYY + IXYIXX + IYXIXX + IYYIYX + IXXIYX))(1.0*t[0]) │»
q_3: ┤3                                                                                            ├»
     │                                                                                             │»
q_4: ┤4                                                                                            ├»
     │                                                                                             │»
q_5: ┤5                                                                                            ├»
     └─────────────────────────────────────────────────────────────────────────────────────────────┘»
«     ┌─────────────────────────────────────────────────────────────────────────────────────────────┐»
«q_0: ┤0                                                                                            ├»
«     │                                                                                             │»
«q_1: ┤1                                                                                            ├»
«     │                                                                                             │»
«q_2: ┤2                                                                                            ├»
«     │  exp(-it (YZYIXY + XZXIXY + XZYIYY + YZXIYY + XZYIXX + YZXIXX + YZYIYX + XZXIYX))(1.0*t[1]) │»
«q_3: ┤3                                                                                            ├»
«     │                                                                                             │»
«q_4: ┤4                                                                                            ├»
«     │                                                                                             │»
«q_5: ┤5                                                                                            ├»
«     └─────────────────────────────────────────────────────────────────────────────────────────────┘»
«     ┌─────────────────────────────────────────────────────────────────────────────────────────────┐
«q_0: ┤0                                                                                            ├
«     │                                                                                             │
«q_1: ┤1                                                                                            ├
«     │                                                                                             │
«q_2: ┤2                                                                                            ├
«     │  exp(-it (YZYXZY + XZXXZY + XZYYZY + YZXYZY + XZYXZX + YZXXZX + YZYYZX + XZXYZX))(1.0*t[2]) │
«q_3: ┤3                                                                                            ├
«     │                                                                                             │
«q_4: ┤4                                                                                            ├
«     │                                                                                             │
«q_5: ┤5                                                                                            ├
«     └─────────────────────────────────────────────────────────────────────────────────────────────┘
[((0, 3), (1, 4)), ((0, 3), (1, 5)), ((0, 3), (2, 5))]

In this context, the goal of this issue is to implement a variant of SUCCD (or an additional keyword argument to its constructor) which results in the inclusion of the ((0, 3), (2, 4)) excitation, while at the same time still using only three parameters (namely t[0]-t[2] in the example above). This should be achieved by ensuring that ((0, 3), (1, 5)) and ((0, 3), (2, 4)) are assigned the same parameter (namely t[1] in the example above).

See also qiskit-community/qiskit-aqua#1486

I did not transfer the issue since there is a PR with a pending fix. There is an issue around PH energy extracted too as I noted that is not catered to. Also with the chemistry code refactor here the 'fix' may end up looking different but whatever the refactor entails the current bug around the extracted energies needs to be corrected, hence this issue.

Migrated from Enterprise Github.
Creator: @mrossinek

What is the expected behavior?

Implement and test the BravyiKitaevMapper.
This issue breaks-out of #18 and can be used to assign and discuss BK-related topics.

• Implementation
• Unittest
• Documentation