✨ Neutral Atom QDMI Device

[ystade]

Description

This PR adds a universal QDMI device implementation for neutral atom-based quantum computers. The device itself is specified in a JSON file whose structure is given by a protobuf definition. During compilation time, the JSON file is read and translated to C++ code similar to how TableGen works in the LLVM project.

Subsequent PRs will add a QDMI driver utilizing the new device and a FoMaC tailored to those neutral atom devices.

Checklist:

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

[ystade]

@burgholzer This PR is far from being ready, that's why it is labeled as Draft. However, it would be very helpful, if you could take a look at how the addition is structured and give feedback on this.

For context: The protobuf file in protocol/na/ is consumed by an executable defined in na/device/App.cpp. This executable parses the JSON in json/na/ and generates a C++ header files that is included in the na/device/Device.cpp file.

[codecov]

Codecov Report

Attention: Patch coverage is 91.38756% with 36 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/na/device/Generator.cpp	90.4%	16 Missing ⚠️
src/na/device/App.cpp	92.6%	10 Missing ⚠️
src/na/device/Device.cpp	91.2%	10 Missing ⚠️

📢 Thoughts on this report? Let us know!

[burgholzer]

Huge props @ystade. This was extremely pleasant to browse through. The current setup feels really solid and I believe all of my comments (which are still quite some), are on fine details and tiny little recommendations that you might have planned anyway. I hope they still provide you with additional food for thought to push this further.

One interesting aspect that I have not yet thought about is how this will play out on Windows once a Driver is involved. But that's something to tackle in a separate PR.

[burgholzer]

Just something to keep in mind: This should probably already consider QDMI 1.2 (or at least the changes that have already landed). AFAIR, this affects how sites are represented and, at least, parts of the job interface.

[ystade]

The new dependency of protobuf is still giving me a few headaches. Same as googletest it depends on abseil. However, when abseil is not installed, both fetch it but in different versions leading to two abseil libraries. Hence, the linker ignores the duplicate library and cannot find the abseil symbols at all during linking. This can either be fixed by installing abseil but in order not to enforce the installation of abseil to users of MQT Core, the other option is to fetch abseil centrally already in the MQT Core configuration.

When doing that, googletest can be instructed to use the available abseil by setting GTEST_HAS_ABSL ON. However, then googletest additionally requires re2. This then has also be added as a dependency in the MQT Core configuration.

Now, the ugly part comes: The cmake configuration of re2 does not allow to disable the generation of install targets. Simulteanously, the re2's install targets require the export targets from abseil, hence, ABSL_ENABLE_INSTALL is set to ON. In summary, this adds a lot of new install targets (that are btw not associated to any components). This then causes issues when building the Python wheel because before #1021 everything was installed into the wheel. After #1021 is merged this should be fixed for now.

However, when we want to ship the QDMI NA device at some point with the Python wheel, we need to be very careful what we include in the Python wheel. Because of #1021 together with the fact that the install targets of re2 do not belong to any component, those cannot be installed anymore in this setup. However, since we should not need to have protobuf itself in the wheel (the auto-generated QDMI NA device should suffice), we probably do not need to install protobuf including the abseil dependency. even if we need protobuf, this still might be possible, as protobuf does connect its install targets to components.

[ystade]

In general, concerning abeil, re2 and perhaps protobuf and googletest we might want to consider to build the separately in the CI workflow, setup proper caching for them and install them such they can be found in MQT Core via find_package.