[refactor] Towards a non-driver focused future

What should we add?

This Epic outlines the plan for the upcoming restructuring of the entire Qiskit Nature code base. Separate issues will be created outlining the refactoring plan for each existing module in more detail. (Some modules/files will not be migrated. See at the bottom of this description.)

Vision

We are undertaking a step away from the existing control flow in which Qiskit Nature uses drivers to handle the electronic structure integral generation by calling other classical codes. Instead, the plan is to design a code- and language-agnostic description (implemented with HDF5) of a problem for Qiskit Nature to solve, which the classical code can generate directly. In this way, the responsibility over the control flow of a calculation is handed over to the classical codes rather than remaining within Qiskit Nature.

This has multiple benefits, a major one being the immediate availability of iterative embedding techniques already implemented in classical codes (e.g. CASSCF). In Qiskit Nature’s current design, only CASCI calculations are possible and an implementation of CASSCF would require a custom driver class for each classical code, which is not scalable for the future.

Another issue will be opened in the near future outlining this vision in more detail and discussing the planned HDF5 file structure.

Code Structure

With such a drastic change in design, we are taking this opportunity to restructure the code base. The following structure roughly outlines the intended new structure:

qiskit_nature/
    second_quantization/
        algorithms/
            excited_state_solvers/
            ground_state_solvers/
            initial_points/
        circuit/
            library/
                ansatzes/
                initial_states/
        operators/
        mappers/
        hamiltonians/
        properties/
        problems/
        transformers/
        drivers/

A more detailed overview including the main classes is given by the following UML:

Workflow

Someone already familiar with Qiskit Nature, should not have much trouble understanding the relations outlined by the following class diagram:

Together with this pseudo code, this should roughly outline the intended workflow:

from qiskit_nature.second_quantization.algorithms.ground_state_solvers import (
    GroundStateEigensolver,
    VQEUCCFactory,
)
from qiskit_nature.second_quantization.mappers import JordanWignerMapper, QubitConverter
from qiskit_nature.second_quantization.drivers import HDF5Driver

problem = HDF5Driver("problem_description.hdf5").run()

solver = GroundStateEigensolver(
    VQEUCCFactory(),
    QubitConverter(JordanWignerMapper()),
)

result = solver.solve(problem)

More details on the various modules will be provided by the respective issues.

Unaffected modules

• constants.py
• deprecation.py
• exceptions.py
• hdf5.py
• logging.py
• optionals.py
• runtime
• settings.py
• utils
• version.py
• VERSION.txt

[mrossinek]

Minor update: I updated the issue description, including the UML graphics, to reflect the design changes as also discussed by @ElePT further up

[mrossinek]

Thanks for the summary, @ElePT! Looks like you got everything right 👍

EDIT: You may want to indicate that ElectronicStructureResult (and similar classes) will become part of the problems module