[cclaudio]

Summary

QFwBackend.run() now forwards param_values and compilation_options to the QFw job info. Before, these options were dropped, and run() printed an "Option … is not used by this backend" warning for them. The PR also adds example scripts and tests for the IBM Quantum System (QSA) path.

Changes

Option propagation (qfw_qiskit: propagate options from options to info)

• backends/qfw_qiskit/qfw_simulator.py: adds QFW_INFO_PASSTHROUGH_OPTIONS = ("param_values", "compilation_options").
  • run() no longer warns about these keys.
  • run() copies them from kwargs into the job options.
• backends/qfw_qiskit/qfw_job.py: QFwJob copies both options into info when they are not None, so they reach the QPM/driver.

IBM QSA examples (examples: add IBM QSA frontend and QPM examples)

• examples/qfw_ibm_frontend.sh: takes a device-access YAML and runs tests/test_ibm_frontend.py. It calls Frontend and QrmiDriver directly, with no QPM.
• examples/qfw_ibm_qpm_local.sh and examples/qfw_ibm_qpm_site.sh: run an IBM QSA job through a local QPM and a site QPM. Both run tests/test_ibm_qpm.py.
• CMakeLists.txt: installs the three new scripts.

[DougSO]

Thanks for this. Couple of notes:

1. qfw_ibm_frontend.sh sources ${QFW_INSTALL_PREFIX}/bin/qfw-activate. QFW_INSTALL_PREFIX comes from the cluster's login profile, not from QFw, so under set -u the script stops with "unbound variable" anywhere else, including a plain docker exec. The other examples don't activate QFw themselves. They expect the user to have done it and check with qfw_example_require_runtime. Could this one do the same?

2. Both QPM scripts pass --owner "${QFW_QSA_OWNER:-user-a}". qfw_slurm_driver.sh already defaults the owner to $USER, and the owner decides whose credential record the reservation uses. With user-a as the default, anyone else who runs the example gets user-a's credential, or a failure where there is no user-a. Could the default be left to the driver?

3. The PR also removes the parameter_values.shape log line in ibm_transcode.py, along with its comment. The description doesn't mention it, and the sample output in QFw-SLURM-Cluster#70's recipe still shows that line. Was that intended? Also, the two new log lines use f-strings, while the rest of the file passes %s arguments.

4. Small things:

   • qfw_ibm_qpm_site.sh --help points to docs/recipes/run-example-ibm-qrmi.md, which doesn't exist. Adding the three scripts to examples/README.md would give them a home.
   • qfw_ibm_qpm_site.sh builds a site config from examples/qfw_shim_device_access.yaml, which has no ibm-fake-lagos entry. In site mode the site QPM reads its own device-access file. Is that step needed?
   • It also passes qsa-qpm-site to qfw_example_setup_site_services, which takes no arguments.
   • test_ibm_qpm.py defines compilation_options and then repeats the literal in run_options.

5. Could you add a mock test for the passthrough? tests/mock/test_qfw_job.py would fit: param_values and compilation_options reach info when set, are left out when None, and run() no longer prints the "not used" warning for them.