Skip to content
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

Remove factor of 6 #161

Merged
merged 1 commit into from
Aug 20, 2024
Merged

Remove factor of 6 #161

merged 1 commit into from
Aug 20, 2024

Conversation

KaterinaGratsea
Copy link
Contributor

@KaterinaGratsea KaterinaGratsea commented Aug 8, 2024

Description

Summary:
The issue involves removing the factor of 6 from BenchQ to correct inconsistencies in the runtime calculation.

Context:
This factor of six is because the syndrome extraction circuits have depth 6 when assuming direct physical ability to initialise and readout qubits in the X-basis. There is a discrepancy in the terminology used, which stems from the historical use of gate_time instead of surface_code_cycle_time. The factor of six needs to be removed to align the equations with the updated terminology.

Implemented solution:
Removed factor of 6 from time_per_circuit_in_seconds in graph_estimator.py in line 469

time_per_circuit_in_seconds = (
    6 * num_cycles * hw_model.surface_code_cycle_time_in_seconds
)

Copy link

github-actions bot commented Aug 8, 2024

🚀 Code Coverage

-------------------------------------------------------------------------------
You are using PYTHON: my_little_venv/bin/python3
Python Version: Python 3.11.9
Repository: https://github.com/zapatacomputing/benchq
Python Modules Covered: src.benchq/algorithms/gsee src.benchq/algorithms/data_structures src.benchq/compilation/circuits src.benchq/compilation/graph_states src.benchq/problem_embeddings/block_encodings src.benchq/problem_embeddings/time_marching src.benchq/problem_embeddings/qaoa src.benchq/problem_embeddings/trotter src.benchq/problem_embeddings/qsp src.benchq/problem_ingestion/molecular_hamiltonians src.benchq/problem_ingestion/solid_state_hamiltonians src.benchq/problem_ingestion/plasma_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                                   36     15    58%   14-19, 92-93, 97-104
src/benchq/compilation/graph_states/compiled_data_structures.py                            54      1    98%   102
src/benchq/compilation/graph_states/implementation_compiler.py                             42      4    90%   86-89
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/magic_state_distillation/autoccz_factories.py                                   45      0   100%
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                                          106     28    74%   42, 56-59, 78, 86, 96, 143-149, 152-155, 169-176, 184-188
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                      117      6    95%   50, 93, 207-211, 264, 270
src/benchq/resource_estimators/azure_estimator.py                                          42     29    31%   19, 58-73, 86-119
src/benchq/resource_estimators/default_estimators.py                                       69     43    38%   129-131, 164, 178-192, 234-281, 292-309
src/benchq/resource_estimators/graph_estimator.py                                         129      9    93%   131, 312, 385-389, 405-417
src/benchq/resource_estimators/openfermion_estimator.py                                    61      2    97%   68, 172
src/benchq/resource_estimators/resource_info.py                                            75      0   100%
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                                                                                    2601    601    77%

Copy link
Collaborator

@pediejo pediejo left a comment

Choose a reason for hiding this comment

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

Looks good! My only suggestion is that in your PR comments that instead of linking to the Jira ticket (which people outside of Zapata can't see) that you paste the content from the Jira ticket into your PR description. This would help someone follow why this change was made.

@@ -467,7 +467,7 @@ def estimate_resources_from_compiled_implementation(

# get time to get a single shot
time_per_circuit_in_seconds = (
6 * num_cycles * hw_model.surface_code_cycle_time_in_seconds
num_cycles * hw_model.surface_code_cycle_time_in_seconds
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a comment: I was surprised to see that the unit tests are still passing after making this change. But, I now see that it is because our tests don't depend on the absolute value of time_per_circuit_in_seconds, but only on how this value is expected to change with respect to other parameters (e.g. physical error rate). I think this is good because it shows that these tests are checking something that we expect to be the case rather than checking output values against values generated from the tests themselves, which are weaker and subject to breaking even when the code is updated properly.

Copy link
Collaborator

@pediejo pediejo left a comment

Choose a reason for hiding this comment

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

Looks good!

@pediejo pediejo merged commit 98c59f9 into main Aug 20, 2024
6 checks passed
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.

2 participants