8000 Pj/dta2 489/basic active volume costing by pediejo · Pull Request #162 · zapatacomputing/benchq · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Pj/dta2 489/basic active volume costing #162

8000
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 41 commits into from
Dec 20, 2024

Conversation

pediejo
Copy link
Collaborator
@pediejo pediejo commented Aug 23, 2024

Description

This PR solves the issue of how alternative logical architecture models (in particular an active volume all-to-all architecture) can be modeled in benchq.
(Note: we've updated the architecture name to "all-to-all" thanks to @AthenaCaesura's helpful suggestion)

Context

Previous methodologies in benchq for determining the cost of graph state preparation assumed a fixed 2D connectivity of logical qubits. Moreover, only the two-row bus logical architecture (a row of data qubits and a row of bus qubits) was being modeled. However, for some physical architectures the physical qubits can connect to more distant physical qubits. Ion trap elementary logical units, for example, can facilitate beyond 2D interactions between ELUs. Simon and Ilia are interested in demonstrating the resource reductions afforded by this connectivity.

Approach

One approach to leveraging this beyond-2D connectivity is to compile to an “active volume” architecture (similar to this). The active volume architecture assumes that the logical data qubits can be "re-ordered" (either for free, or ,in the case of the Litinski paper, with some small overhead). Simon Devitt has outlined an approach to modifying the accounting of graph state creation cost within benchq for the purposes of compiling to an active volume architecture. For simplicity, we will neglect the cost of reordering the data qubits (which is analogous to assuming an all-to-all connectivity). In the future we plan to incorporate the costs of reordering. There are two main accounting changes:

Temporal: updating the number of tocks per graph state creation

Currently, the julia functions time_optimal_two_row_scheduler and space_optimal_two_row_scheduler in benchq count the number of graph state creation tocks based on the two-row lay-out. For the active volume accounting, analogs of these functions would need to count the number of tocks according to a relaxed notion of co-measurable stabilizers.

Spatial: updating accounting of the number of data and bus qubits

The number of data qubits in the active volume architecture is supposed to be the maximum number of nodes in the graph among the graphs over each layer. This is because the bus is not needed to facilitate long-range stabilizer measurements. Instead, the data qubits can be connected in any manner and so a single stabilizer measurement involves choosing a linear connectivity over the qubits and using lattice surgery operations to make the stabilizer measurement.

Challenges

There were three main challenges with implementing this PR

  • Develop the julia code functionality to schedule the stabilizer measurements for the active volume (see changes in substrate_scheduler.jl)
  • Refactor the resource estimation logic to enable "swapping" in one logical architecture for another (see changes in graph_estimator.py)
  • Develop the classes and methods that enact and store logical-architecture-specific resource accounting (see new modules in graph_based_logical_architectures.py)

Notes

  • Due to the introduction of objects that express logical architecture models, the interface for the resource estimation methods of the GraphEstimator changed. This led to making updates throughout the examples and the tests.
  • A bug was fixed in the time_optimal_two_row_scheduler function where we replaced "&"s with "&&"s so that certain "if statements" that were not being triggered are now triggered. This led to an increase in the runtimes of corresponding resource estimates.
  • A bug was fixed in the T and rotation measurement accounting, where they were previously being undercounted. The issue was that, while all T/rotation measurements in a layer should be counted, we were only counting those that were on nodes whose stabilizers were being measured in that layer (as opposed to those that are initialized in |+>).
  • We simplified the logic for allocating error budget across rotation synthesis, distillation, and qec, making the methodology more similar to that of Appendix E in https://arxiv.org/abs/2211.07629. This facilitates a better apples-to-apples comparison of resource estimates.
  • We made changes to fields stored in the ResourceInfo object here. We have attempted to reorganize this object to 1) expose some basic info about the resources (n_abstract_logical_qubits, n_t_gates, n_physical_qubits, runtime) along with more detailed info at various levels in the computational stack (abstract_logical_resource_info, logical_architecture_resource_info, hardware_resource_info, decoder_info).
  • For the time being, we have removed dependence on the Azure Quantum Resource Estimator. The reason is that the integration had not been maintained and the changes made to the BenchQ logical architecture accounting warrant an update to how the fields would be populated from the Azure QRE tool.
  • We have stopped support for Orquestra workflows due to Orquestra no longer being maintained.

Please verify that you have completed the following steps

  • I have self-reviewed my code.
  • I have included test cases validating introduced feature/fix.
  • I have updated documentation.

@pediejo pediejo marked this pull request as ready for review September 4, 2024 20:35
@AthenaCaesura
Copy link
Contributor
AthenaCaesura commented Sep 6, 2024

Hello! So first things first I would have to put my objection to calling this "Active Volume" in writing. As the changes here work with a machine that doesn't satisfy all of the AV assumptions (single cycle bell state preparations and measurements being one of them). It would be much better to call this something like "All to all logical connectivity."

Comment on lines +92 to 97
if node_to_patch[neighbor] < bar[1] && node in curr_physical_nodes
bar[1] = node_to_patch[neighbor]
end
if node_to_patch[neighbor] > bar[2] & node in curr_physical_nodes
if node_to_patch[neighbor] > bar[2] && node in curr_physical_nodes
bar[2] = node_to_patch[neighbor]
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this could be change to sth like:

if node in curr_physical_nodes bar[1] = min(bar[1], node_to_patch[neighbor]) bar[2] = max(bar[2], node_to_patch[neighbor]) end

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @KaterinaGratsea! Do you mind explaining this suggestion a bit more? What is the problem that it solves?

Copy link
github-actions bot commented Dec 18, 2024

🚀 Code Coverage

-------------------------------------------------------------------------------
You are using PYTHON: my_little_venv/bin/python3
Python Version: Python 3.11.11
Repository: https://github.com/zapatacomputing/benchq
Python Modules Covered: src.benchq/problem_embeddings/qaoa src.benchq/problem_embeddings/time_marching src.benchq/problem_embeddings/qsp src.benchq/problem_embeddings/trotter src.benchq/problem_embeddings/block_encodings src.benchq/algorithms/gsee src.benchq/algorithms/data_structures src.benchq/compilation/circuits src.benchq/compilation/graph_states src.benchq/problem_ingestion/plasma_hamiltonians src.benchq/problem_ingestion/solid_state_hamiltonians src.benchq/problem_ingestion/molecular_hamiltonians
-------------------------------------------------------------------------------
my_little_venv/bin/python3 -m coverage report --show-missing
Name                                                                                    Stmts   Miss  Cover   Missing
---------------------------------------------------------------------------------------------------------------------
src/benchq/algorithms/data_structures/algorithm_implementation.py                          20      1    95%   37
src/benchq/algorithms/data_structures/error_budget.py                                      19      0   100%
src/benchq/algorithms/gsee/ld_gsee.py                                                      15      0   100%
src/benchq/algorithms/gsee/qpe_gsee.py                                                     16     16     0%   1-24
src/benchq/algorithms/profolio_optimization.py                                              6      6     0%   4-27
src/benchq/algorithms/time_evolution.py                                                    30      0   100%
src/benchq/compilation/circuits/compile_to_native_gates.py                                121      1    99%   149
src/benchq/compilation/circuits/pyliqtr_transpilation.py                                   32      0   100%
src/benchq/compilation/graph_states/circuit_compilers.py                                   39     17    56%   14-19, 89-90, 105-106, 110-117
src/benchq/compilation/graph_states/compiled_data_structures.py                            51      5    90%   94-105
src/benchq/compilation/graph_states/implementation_compiler.py                             42      4    90%   95-98
src/benchq/compilation/graph_states/initialize_julia.py                                    14      0   100%
src/benchq/compilation/graph_states/substrate_scheduler/python_substrate_scheduler.py      30      6    80%   36, 44, 52, 57-59
src/benchq/conversions/_circuit_translations.py                                            28      1    96%   53
src/benchq/conversions/_openfermion_pyliqtr.py                                             18      0   100%
src/benchq/conversions/_operator_translations.py                                           30      4    87%   35, 40, 45, 58
src/benchq/decoder_modeling/decoder.py                                                     48      1    98%   116
src/benchq/decoder_modeling/decoder_resource_estimator.py                                  30      0   100%
src/benchq/logical_architecture_modeling/basic_logical_architectures.py                     6      2    67%   3, 7
src/benchq/logical_architecture_modeling/graph_based_logical_architectures.py             131     12    91%   111-120, 152, 169, 191, 240, 264, 368
src/benchq/magic_state_distillation/autoccz_factories.py                                   45      0   100%
src/benchq/magic_state_distillation/factory_selection.py                                   20      1    95%   42
src/benchq/magic_state_distillation/litinski_factories.py                                   9      0   100%
src/benchq/magic_state_distillation/small_footprint_factories.py                            8      8     0%   1-81
src/benchq/mlflow/data_logging.py                                                          44      1    98%   43
src/benchq/problem_embeddings/block_encodings/double_factorized_hamiltonian.py             14      0   100%
src/benchq/problem_embeddings/block_encodings/offset_tridiagonal.py                        27      0   100%
src/benchq/problem_embeddings/block_encodings/offset_tridiagonal_utils.py                  40      0   100%
src/benchq/problem_embeddings/qaoa/_qaoa.py                                                14      4    71%   47-50
src/benchq/problem_embeddings/qpe.py                                                       29      0   100%
src/benchq/problem_embeddings/qsp/_lin_and_dong_qsp.py                                     34      0   100%
src/benchq/problem_embeddings/qsp/_qsp.py                                                 114      2    98%   313, 315
src/benchq/problem_embeddings/qsp/get_qsp_phases.py                                       193    184     5%   79-182, 203-225, 239-261, 277-284, 304-371, 397-428
src/benchq/problem_embeddings/qsp/get_qsp_polynomial.py                                    42      3    93%   112-115
src/benchq/problem_embeddings/quantum_program.py                                          108     29    73%   42, 56-59, 78, 86, 96, 133, 146-152, 155-158, 172-179, 187-191
src/benchq/problem_embeddings/time_marching/_time_marching.py                             107     14    87%   75, 287-314
src/benchq/problem_embeddings/time_marching/compression_gadget.py                          13      0   100%
src/benchq/problem_embeddings/time_marching/matrix_properties.py                           13      0   100%
src/benchq/problem_embeddings/trotter/_trotter.py                                          12      2    83%   13, 26
src/benchq/problem_ingestion/hamiltonian_from_file.py                                      74      2    97%   94, 120
src/benchq/problem_ingestion/molecular_hamiltonians/_common_molecules.py                   13      0   100%
src/benchq/problem_ingestion/molecular_hamiltonians/_compute_lambda.py                     18      0   100%
src/benchq/problem_ingestion/molecular_hamiltonians/_hamiltonian_generation.py            161     11    93%   136, 139, 145, 148, 167, 230, 240, 322-324, 539
src/benchq/problem_ingestion/plasma_hamiltonians/vlasov.py                                 12      0   100%
src/benchq/problem_ingestion/solid_state_hamiltonians/fermi_hubbard.py                      7      3    57%   17-29
src/benchq/problem_ingestion/solid_state_hamiltonians/heisenberg.py                        20     14    30%   19-44
src/benchq/problem_ingestion/solid_state_hamiltonians/ising.py                             90     43    52%   17-24, 42-49, 53-75, 79-91
src/benchq/quantum_hardware_modeling/devitt_surface_code.py                                14      0   100%
src/benchq/quantum_hardware_modeling/fowler_surface_code.py                                 6      0   100%
src/benchq/quantum_hardware_modeling/hardware_architecture_models.py                      119      7    94%   50, 93, 99, 211-215, 268, 274
src/benchq/resource_estimators/default_estimators.py                                       41     14    66%   140-142, 177, 192-206, 218-235
src/benchq/resource_estimators/graph_estimator.py                                          74     10    86%   103-107, 152, 176, 189-190, 203
src/benchq/resource_estimators/openfermion_estimator.py                                    61      2    97%   68, 172
src/benchq/resource_estimators/resource_info.py                                           104      4    96%   116, 121, 127, 129
src/benchq/timing.py                                                                       17      0   100%
src/benchq/visualization_tools/plot_graph_state.py                                         76     69     9%   19-230
src/benchq/visualization_tools/plot_substrate_scheduling.py                                28     15    46%   26-47
src/benchq/visualization_tools/resource_allocation.py                                     119     53    55%   112-115, 119-143, 146-220
---------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                    2666    571    79%

@pediejo pediejo requested a review from max-radin December 18, 2024 02:59
@pediejo pediejo merged commit 80b8279 into main Dec 20, 2024
6 checks passed
@pediejo pediejo deleted the pj/DTA2-489/basic_active_volume_costing branch December 20, 2024 21:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0