Support dynamic quantum architecture for IQM QPUs #3298
Conversation
For IQM machines fetch the quantum architecture from server, derive the dynamic architecture from this and write it to an architecture file. This file is then passed in the lowering pipeline in place of the previously used static architecture files. The output from the algorithm for finding usable qubits generates a list of qubits which are calibrated for mz, cz and prx. A mapping ensures that qubit names are enumerated in a linear manner and not fully calibrated qubits do not show in the architecture file. The architecture file is created in the system temp directory with a unique filename and deleted after the job has been sent to the IQM server. Changes in function * Removed parameter "--iqm-machine" which was used to specify the IQM quantum architecture at compile time. * Removed static architecture files provided for Adonis, Apollo, and Aphrodite architectures. * Removed machine architecture bindings from IQM tests. * Implemented getting the authorization token from IQM_TOKEN environment variable. If this is not set the previous mechanism reading the token from a JSON file is used. * Updated IQM JSON output of LLVM to latest syntax. "phased_rx" -> "prx", "measurement" -> "measure" in both emitter code and tests. Test related changes * Adapted IQM mock server to latest iqmclient API version (v28.0.0) and IQM server API changes. * Implemented in IQM mock server the 20 qubit Apollo quantum architecture. * Added support for mapping of qubits syntax in the job request to the mock server. * In the mock server deliberately removed QB2 and QB3 from the list of PRX calibrated gates. This results in changes in the topology and forces the CUDA-Q code to work with an imperfect calibrated system. This tests the implemented algorithm with every testcase which uses more than 1 qubit. * In mock server implemented a full checking of gates used in circuits versus the topology to verify that all 2 qubit gates are supported by the mock qpu. * Pass the authorization token to IQM mock server with env-variable. This includes also a new testcase addressing the IQM_TOKEN environment variable. * Save and restore environment variables for testcases modifying them. So the order of testcases does not matter anymore. * Fixed evaluation of 2 qubit testcases which failed on some simulations. Documentation * Updated the IQM parts of the documentation and examples. Explained changes from previous version and removed references to the no longer needed machine names. * Cleanup: improved doxygen headers and few other comments. * Cleanup: Added copyright to touched files Addresses issues: NVIDIA#1589, NVIDIA#865 --------- Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com> Signed-off-by: iqm-bhoffmann <bernd.hoffmann@meetiqm.com>
Merge branch 'main' of https://github.com/iqm-bhoffmann/cuda-quantum into support-iqm-dynamic-quantum-architecture Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
iqm-bhoffmann
requested review from
bettinaheim,
1tnguyen,
bmhowe23 and
schweitzpgi
as code owners
Command Bot: Processing... |
Signed-off-by: Sachin Pisal <spisal@nvidia.com>
Command Bot: Processing... |
Commented out debug output dumping JSON data. The code worked earlier but now fails compilation reporting a type issue. Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
Instead of fixing a formatting error removed some debug prints entirely as they are just details of a more general previous printout. Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Fixed implementation of --emulate parameter. Previously it tried load the dynamic quantum architecture from server despite "emulate" means without server. This caused several ctests to fail. Removed the --iqm-machine parameter from all ctest lines in the various C++ test programs. Adapted the ctests mapping testcase to use a Crystal_5.txt file and restored this to the project. Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
In emulation mode provide a mapping file for the 20 qubit crystal architecture. Restored the Crystal_20.txt (former Apollo.txt) mapping file. This is used only in emulation mode. Added header file <unistd.h> which was missing in IQMServerHelper. Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
Signed-off-by: iqm-bhoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
After feedback in internal review corrected: - Wording of some comments. - Improved writing of the bit encoded flag variable. Only for readability - non functional change. - Removed an unused include. Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
Signed-off-by: Bernd Hoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Signed-off-by: iqm-bhoffmann <bernd.hoffmann@meetiqm.com>
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
|
The currently failing checks are not related to the contributed code but infrastructure issues. One failing test is about a socket failing to bind and another test fails when git fails to complete a fetch due to a "unexpected disconnect". |
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Command Bot: Processing... |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
There was a problem hiding this comment.
With this setup, I think we should no longer have any architecture files checked in in the runtime. The Crystal_5 and Crystal_20 files used for testing can be added to the appropriate test directory instead.
| add_target_mapping_arch(iqm "Crystal_5.txt") | ||
| add_target_mapping_arch(iqm "Crystal_20.txt") | ||
| add_target_mapping_arch(iqm "Crystal_54.txt") | ||
| add_target_mapping_arch(iqm Crystal_20.txt) |
There was a problem hiding this comment.
This should also be removed here, and instead someone that uses emulation should create an appropriate file themselves (maybe we can have an option to dump the architecture file for a specific url instead of deleting it?). The section in the docs about emulation needs to clarify this, and could link to the files used for testing as an example.
| case $filename in | ||
| targettests/iqm/*) | ||
| nvq++ -DSYNTAX_CHECK --target iqm --iqm-machine Crystal_5 $filename | ||
| nvq++ -DSYNTAX_CHECK --target iqm $filename |
There was a problem hiding this comment.
I gather the new setup is that different machines will be accessible via different server urls?
If so, would we be able to test against at least two different topologies for our integration tests?
| // Compile and run with: | ||
| // ``` | ||
| // nvq++ --target iqm iqm.cpp --iqm-machine Crystal_5 -o out.x && ./out.x | ||
| // nvq++ --target iqm iqm.cpp -o out.x && ./out.x |
There was a problem hiding this comment.
Generally, we try to make sure that changes are non-breaking (current API still works but gives a deprecated warning for some time before we remove it in favor of a different API). It would be good if we could have one test for python and one for C++ that checks the old API still works (possibly giving a warning or error if necessary with instructions for what should be used instead).
There was a problem hiding this comment.
Since the architecture information is now fetched from the target machine (URL) giving it as parameter is no longer necessary and the parsing of the parameter was removed. From backward compatibility point nothing bad will happen if it is still given. It can however be confusing that this parameter is ignored and we can give a warning/information about this if desired.
Good point about a testcase for the behaviour if the parameter is still given. I will add such test.
| The IQM backend integration now contacts at runtime the configured IQM server and fetches the active dynamic quantum architecture of the QPU. | ||
| This is then used as input to transpile the quantum kernel code just-in-time for the target QPU topology. | ||
| By setting the environment variable ``IQM_SERVER_URL`` the target server can be selected just when executing the program. | ||
| As result the python script or the compiled C++ program can be executed on different QPUs without any changes to the code. |
There was a problem hiding this comment.
nit:
| As result the python script or the compiled C++ program can be executed on different QPUs without any changes to the code. | |
| As result the python script or the compiled C++ program can be executed on different QPUs without recompilation or code changes. |
| .. code:: bash | ||
| nvq++ --emulate --target iqm --iqm-machine Crystal_5 src.cpp | ||
| nvq++ --emulate --target iqm src.cpp |
There was a problem hiding this comment.
I believe emulation would not work fully as expected - it would not do include the layout for a specific device.
Let me get back on that with some options.
There was a problem hiding this comment.
In case of emulation the code currently uses the static Crystal_20.txt file as architecture. This is more a workaround than a solution since there is no machine in this case. With this the emulation testcases pass while they stay below 20 qubits (basically). We still allow the user to pass a "mapping_file" but I would not expect that anybody would do this for the emulation mode. There is the "mapping" testcase which still uses and tests this parameter.
Because the emulator does not have a fixed architecture (I think it takes it from the architecture file) I at first thought that I could do without the architecture file but soon found that this ends in sporadic crashes. So I supplied the above mentioned static architecture file. But it could also be any other architecture file and does not even have to reflect an IQM architecture. The options I see are:
- we generate an generic square lattice architecture file with a defined number of qubits
- we generate an architecture file for an IQM crystal architecture of 20/54/150 qubits
- we enforce that the user has to give an architecture file in emulation mode
The generated files would be temporary just like the ones the code generates with this change from the IQM machines. For solution 2 the size of the architecture could be either hardcoded or given as parameter. For simplification I would however just hardcode the biggest one. Solution 3 seems to be the most cumbersome for the user as it requires to be in possession of an architecture file. I would avoid that.
I would be happy to know your take on this.
| emulation_mode = iter->second == "true"; | ||
| } | ||
|
|
||
| // In emulation mode no server is contacted. So there is no need for |
There was a problem hiding this comment.
This either is no longer true and the server is contacted to get the architecture, or emulation does not fully compile for a specific architecture, or we provide the alternative to configure the architecture locally without contacting the server.
There was a problem hiding this comment.
Current implementation is that no server is contacted in emulation mode.
But reading this gives me a 4th idea to the discussion of the architecture file. The flow could be to get the dynamic quantum architecture from an IQM server and write it to a file and then pass it to the LLVM which runs in emulation mode. Drawback of this solution is that it requires a connection to an IQM server with proper authorization. Not sure if such a hybrid mode is a good solution.
| fetchQuantumArchitecture(); | ||
| pathToFile = writeQuantumArchitectureFile(); | ||
| } else { | ||
| // In emulation mode there is no server information so no mapping file |
There was a problem hiding this comment.
Seeing where you are going with this, I think it would be nice if a quantum architecture file could be manually created and supplied as an argument instead of --iqm-machine. If that argument is provided, then it should take precedence over the server information. That argument should be used for emulation, and a warning should be printed if emulation is used but no architecture file has been specified.
There was a problem hiding this comment.
Such parameter already exists a few lines above with "mapping_file". This is for a testcase and has highest priority if given in the backend string. When we agree on a solution for the architecture file in the other discussions this will be adapted accordingly.
| required: false | ||
| type: string | ||
| platform-arg: url | ||
| help-string: "Specify URL." |
There was a problem hiding this comment.
See suggestion above to instead expose an optional argument topology here.
|
@iqm-bhoffmann Thank you for this update. This will be very nice to have. |
|
Thank you @bettinaheim for reviewing this pr. Sorry for the late response. I was on my annual summer vacation and therefore offline. |
Description
For IQM machines fetch the quantum architecture from server, derive the dynamic architecture from this and write it to an architecture file. This file is then passed in the lowering pipeline in place of the previously used static architecture files.
The output from the algorithm for finding usable qubits generates a list of qubits which are calibrated for mz, cz and prx. A mapping ensures that qubit names are enumerated in a linear manner and not fully calibrated qubits do not show in the architecture file. The architecture file is created in the system temp directory with a unique filename and deleted after the job has been sent to the IQM server.
Changes in function
Test related changes
Documentation
Addressed issues
#1589, #865