Fidelity-aware heuristic and search graph visualization

[EliasLF]

Description

Includes a new fidelity-aware heuristic (+some changes to the current heuristic mapping system making it compatible with the new approach) and a Python visualization module for visualizing search graphs after mapping.

Known issues:

• The fidelity-aware heuristic mapping is not yet compatible with dynamic initial layouting, lookahead or qubit teleportation.
• Some circuits take extremely long during the mapping process due to the high non-convexity of the cost function in the fidelity-aware case. A few techniques for premature search termination (trading guaranteed local optimality for acceptable mapping times in all cases) are planned for another PR in the near future.

Because of those issues, there is 1 test case, that I have only added as a comment for now (since, though running successfully, it takes up to an hour depending on the hardware it is run on) and I did not yet add an example for fidelity-aware mapping in Mapping.ipynb in the documentation. (I think advertising this feature outside the API reference only makes sense once it is more fleshed out)

Checklist:

• The pull request only contains commits that are related to it.
• I have added appropriate tests and documentation.
• I have made sure that all CI jobs on GitHub pass.
• The pull request introduces no new warnings and follows the project's style guidelines.

[EliasLF]

It seems all actions fail because git is unable to find some submodules. I do not have enough insight into how the GitHub Actions are set up on this repo. Are those errors due to the setup or am I at fault here?

[burgholzer]

Here's one change that should most likely not be part of the PR.
The qfr project is superseded by the mqt-core library since a couple months (although this was just a rename of the repository).
The PR in it's current state is adding that qfr submodule back.
That's the most likely reason for all of the CI failing.

[EliasLF]

Oh that's right, I should have caught that on the file diff list. Thank you!
Although, it seems the root problem was a corrupted git repo/branch on my end. I think the cleanest solution is to just create a new branch and submit another PR for that branch containing my implementation. Since we introduce PRs with squash commits into the main branch, there won't be any difference anyways.

I'm closing this PR now and opening an equivalent one shortly.

PS: After resetting my local setup I got QMAP to compile on Windows directly for the first time. So it seems the new mqt_core implementation really is more stable. That's great!

[burgholzer]

Oh that's right, I should have caught that on the file diff list. Thank you!

Although, it seems the root problem was a corrupted git repo/branch on my end. I think the cleanest solution is to just create a new branch and submit another PR for that branch containing my implementation. Since we introduce PRs with squash commits into the main branch, there won't be any difference anyways.

I'm closing this PR now and opening an equivalent one shortly.

Sounds good!

PS: After resetting my local setup I got QMAP to compile on Windows directly for the first time. So it seems the new mqt_core implementation really is more stable. That's great!

Nice. Glad to hear that!