Dta2-255 consistent naming #139

AthenaCaesura · 2023-11-03T13:50:56Z

Description

Renamed several variables to ensure consistency in:
- Units are expressed properly
- Estabilishsing naming conventions for functions
Using a single MagicStateFactory class rather than using two separate classes (ours and OpenFermion's)
Rename and rearrange some files to better explain what's going on within them

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.

github-actions · 2023-11-03T14:06:02Z

🚀 Code Coverage

-------------------------------------------------------------------------------
You are using PYTHON: my_little_venv/bin/python3
Python Version: Python 3.11.7
Repository: https://github.com/zapatacomputing/benchq
Python Modules Covered: src.benchq/problem_embeddings/time_marching src.benchq/problem_embeddings/block_encodings src.benchq/problem_embeddings/qsp src.benchq/resource_estimators/footprint_estimators src.benchq/resource_estimators/graph_estimators src.benchq/algorithms/gsee src.benchq/algorithms/data_structures src.benchq/problem_ingestion/solid_state_hamiltonians src.benchq/problem_ingestion/molecule_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                   15      0   100%
src/benchq/algorithms/data_structures/error_budget.py                               19      0   100%
src/benchq/algorithms/data_structures/graph_partition.py                            24      4    83%   21-24
src/benchq/algorithms/gsee/ld_gsee.py                                               16      0   100%
src/benchq/algorithms/gsee/qpe_gsee.py                                              17     17     0%   1-26
src/benchq/algorithms/profolio_optimization.py                                       6      6     0%   4-27
src/benchq/algorithms/time_evolution.py                                             29      0   100%
src/benchq/compilation/initialize_julia.py                                          14      0   100%
src/benchq/compilation/julia_utils.py                                               43      2    95%   82-83
src/benchq/compilation/pyliqtr_transpilation.py                                     26      0   100%
src/benchq/compilation/rbs_hyperparam_tuning.py                                     93     41    56%   85, 160-161, 209-219, 260-270, 311-321, 349-360, 391-417, 441-448
src/benchq/compilation/transpile_to_native_gates.py                                 96      1    99%   107
src/benchq/conversions/_circuit_translations.py                                     28      1    96%   53
src/benchq/conversions/_openfermion_pyliqtr.py                                      17      0   100%
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                           15      0   100%
src/benchq/magic_state_distillation/magic_state_factory.py                          10      0   100%
src/benchq/mlflow/data_logging.py                                                   45      1    98%   43
src/benchq/problem_embeddings/_qaoa.py                                              14      4    71%   47-50
src/benchq/problem_embeddings/_trotter.py                                           12      2    83%   13, 26
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/qpe.py                                                28      0   100%
src/benchq/problem_embeddings/qsp/_lin_and_dong_qsp.py                              34      0   100%
src/benchq/problem_embeddings/qsp/_qsp.py                                          115      2    98%   314, 316
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                                    58      4    93%   33, 63, 71, 79
src/benchq/problem_embeddings/time_marching/_time_marching.py                      107     14    87%   75, 285-312
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_ingestion/hamiltonian_from_file.py                               75      2    97%   94, 120
src/benchq/problem_ingestion/molecule_hamiltonians/_compute_lambda.py               18      0   100%
src/benchq/problem_ingestion/molecule_hamiltonians/instances.py                    202     11    95%   145, 148, 154, 157, 176, 246, 271, 362-366, 546
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                          7      0   100%
src/benchq/quantum_hardware_modeling/hardware_architecture_models.py                69      4    94%   31, 35, 44, 188
src/benchq/resource_estimators/azure_estimator.py                                   46     31    33%   19, 60-66, 72-83, 93-126
src/benchq/resource_estimators/default_estimators.py                                63     37    41%   132-139, 176-183, 200-218, 259-297, 307-324
src/benchq/resource_estimators/footprint_estimators/openfermion_estimator.py        62      2    97%   65, 169
src/benchq/resource_estimators/graph_estimators/customizable_pipelines.py           39      2    95%   89-94
src/benchq/resource_estimators/graph_estimators/extrapolation_estimator.py          81      2    98%   84, 116
src/benchq/resource_estimators/graph_estimators/graph_estimator.py                 131     10    92%   155, 176, 204, 348-352, 367-376
src/benchq/resource_estimators/graph_estimators/transformers.py                     55      4    93%   74-80
src/benchq/resource_estimators/resource_info.py                                     72      1    99%   97
src/benchq/timing.py                                                                17      0   100%
src/benchq/visualization_tools.py                                                   75     75     0%   4-174
--------------------------------------------------------------------------------------------------------------
TOTAL                                                                             2501    528    79%

mstechly · 2023-11-14T00:22:02Z

Hey @AthenaCaesura, I just spotted that you have typo in hiesenburg in ex_2_time_evolution :)
Cheers!

AthenaCaesura · 2023-11-14T14:03:11Z

@mstechly 😆 Not the first time that's happened.

max-radin · 2023-11-14T19:37:20Z

src/benchq/problem_ingestion/block_encodings/offset_tridiagonal.py

I think we might want to move this to problem_embeddings instead of problem_ingestion because it is generating a circuit that encodes the problem. I imagine that problem ingestion in this context would be logic for choosing values of n, a, b, and c for some use case.

I agree! We haven't discussed problem_ingestion vs problem_embedding in detail yet. But the difference I see is:
ingestion - code that converts a classical problem instance into problem instance data for embedding (e.g. pyscf converting the mol geometries into an active space truncated second quantized Hamiltonian or predicting the condition number or norms of the various matrices and vectors in a diff eq problem instance)
embedding - code that converts classical problem instance data into quantum operations (e.g. block encoding the Hamiltonian, oracles for the diff eq A matrix or the b state, trotter steps)
What I'm not sure of though is, based on this terminology, what is the best way to organize the directory structure.

max-radin · 2023-11-14T19:51:45Z

src/benchq/quantum_hardware_modeling/hardware_architecture_models.py

        self.surface_code_cycle_time_in_seconds = surface_code_cycle_time_in_seconds

-    def get_hardware_resource_estimates(self, resource_info: ResourceInfo):
+    def get_hardware_resource_estimates(self, resource_info):


Can we keep the type hint for resource_info?

Yes! Not sure why that got deleted.

max-radin · 2023-11-14T19:56:27Z

src/benchq/resource_estimators/resource_info.py

Instead of using kW/kJ everywhere, would it be better to use W/J? My guess is that using W/J will be less confusing, especially since the decoder energy and power is usually much less than 1 kW/kJ.

I decided to keep the power and energy units as kW/kJ in the case of the IonTrap hardware model as that range is more readable for the typical output. However I did change the decoder to W/J.

max-radin · 2023-11-16T22:03:52Z

src/benchq/resource_estimators/footprint_estimators/azure_estimator.py

I'm wondering whether it really makes sense to put the Azure integration under footprint_estimators. In the context of DARPA QB, I've been interpreting footprint analysis to mean that you estimate physical costs based on the gate count and number of qubits, and not any information about the order of gates or what qubits they act on. Is this what you are thinking the scope of the footprint_estimators module to be?

My impression is that Azure does actually look at the circuit itself, not just gate/qubit counts. (At least from an API point of view it does; it's less clear to me what information about the circuit gets used under the hood.)

According to the last presentation I saw from them, it seems that their tool is "compiling down to an instruction set architecture (ISA)" and using this in their resource estimates. I assume this ends up taking Clifford costs into account.

I think I would rather work on the level of resource estimation methods that require ordering vs. don't require ordering. But this is something we should chat about later on.

max-radin · 2023-11-16T22:21:41Z

One question on my mind is if we can make the organization of the problem ingestion submodule a bit more logical. I'm not sure what the best solution is but a few thoughts:

I think it might be better to have a more specific module name than lanl_maglab because people outside of DARPA QB won't have the context for this. It also would be good to be consistent with the naming scheme for other submodules, like vlasov and heisenberg.
It's a bit counterintuitive to have the Fermi-Hubbard model under jordan_wigner. It's true that we are using Jordan Wigner to encode the Fermi-Hubbard model, but I think the fact that it is the Fermi-Hubbard model is more salient than which encoding it's using.

pediejo

Overall I think these changes you made will help people more easily navigate benchq! Made a few suggestions. Happy to chat about them :-)

pediejo · 2023-12-07T17:00:35Z

examples/ex_2_time_evolution.py

 from benchq.problem_ingestion import get_vlasov_hamiltonian
-from benchq.problem_ingestion.hamiltonian_generation import (
+from benchq.problem_ingestion.hamiltonians.hiesenburg import (


Typo: "hiesenburg" to "heisenberg"

pediejo · 2023-12-08T14:49:07Z

src/benchq/problem_ingestion/block_encodings/offset_tridiagonal.py

I agree! We haven't discussed problem_ingestion vs problem_embedding in detail yet. But the difference I see is:
ingestion - code that converts a classical problem instance into problem instance data for embedding (e.g. pyscf converting the mol geometries into an active space truncated second quantized Hamiltonian or predicting the condition number or norms of the various matrices and vectors in a diff eq problem instance)
embedding - code that converts classical problem instance data into quantum operations (e.g. block encoding the Hamiltonian, oracles for the diff eq A matrix or the b state, trotter steps)
What I'm not sure of though is, based on this terminology, what is the best way to organize the directory structure.

pediejo · 2023-12-08T14:51:34Z

src/benchq/problem_ingestion/block_encodings/utils/_compute_lambda.py

I would suggest that block encoding related material go into problem_embedding rather than problem_ingestion (see related comment above).

I would think that this fits better in problem_ingestion since it is not computing a circuit, but rather is computing the data required to make the circuit.

pediejo · 2023-12-08T14:52:21Z

src/benchq/problem_ingestion/block_encodings/utils/offset_trdiagonal_utils.py

(Same comment as above) I would suggest that block encoding related material go into problem_embedding rather than problem_ingestion.

pediejo · 2023-12-08T14:57:30Z

src/benchq/quantum_hardware_modeling/devitt_surface_code_model.py

If possible, it would be great to add links to arxiv papers as references for the numbers used in these models. We should ask Simon if there is a specific reference he can give us for this.

I'm just going to link to the overleaf for now. 😆

Ok, simon hasn't granted access for sharing the overleaf file. We should bug him about it this week.

pediejo · 2023-12-08T18:43:27Z

src/benchq/quantum_hardware_modeling/gidney_surface_code_model.py

It might be more appropriate to call this fowler_surface_code_model.py since I believe the numbers comes from earlier work by fowler. Also, we should add a reference for the numbers used.

Done! I just cited the openfermion package where all these equations can be found. I'm not sure there is published literature about their exact assumptions.

pediejo · 2023-12-08T19:01:06Z

src/benchq/resource_estimators/footprint_estimators/azure_estimator.py

According to the last presentation I saw from them, it seems that their tool is "compiling down to an instruction set architecture (ISA)" and using this in their resource estimates. I assume this ends up taking Clifford costs into account.

pediejo · 2023-12-08T19:03:10Z

src/benchq/resource_estimators/footprint_estimators/openfermion_re.py

Maybe this should live in problem_embeddings (see similar suggestions above)?

pediejo · 2023-12-08T19:05:06Z

tests/benchq/algorithms/test_lde_solver.py

@@ -11,7 +11,7 @@
 from orquestra.quantum.circuits import ZZ, Circuit
 from qiskit import Aer, execute

-from benchq.algorithms.lde_solver import (
+from benchq.algorithms.lde_solver.lde_solver import (


Should the folder be "lde_solvers" if we're intending to put more than one?

I'm just going to keep it as the singular lde solver for now. In that case, I'll probably change the name to time-marching.

…aming

max-radin

Just one minor comment: hiesenberg.py should be heisenberg.py.

AthenaCaesura added 3 commits October 30, 2023 11:36

feat: refactor magic state distillation

ab94298

fix: merge conflicts

e2a2039

feat: make tests reflect new structure

4b0933b

AthenaCaesura requested a review from max-radin as a code owner November 3, 2023 13:50

AthenaCaesura added 2 commits November 3, 2023 09:54

feat: rename upper level files

95978f8

fix: test file names

57ec93a

fix: problem_embedding -> problem_embeddings

bf41f6b

max-radin reviewed Nov 14, 2023

View reviewed changes

max-radin reviewed Nov 16, 2023

View reviewed changes

pediejo reviewed Dec 10, 2023

View reviewed changes

AthenaCaesura added 4 commits January 9, 2024 11:21

feat: final organization of src

fd8f229

Merge remote-tracking branch 'origin' into DTA2-DTA2-255-consistent-n…

6714c09

…aming

fix: organize tests to reflect src

0dbd97b

fix: passes muster

c9d8a71

AthenaCaesura force-pushed the DTA2-DTA2-255-consistent-naming branch from acabaaf to c9d8a71 Compare January 9, 2024 21:00

AthenaCaesura requested review from max-radin and pediejo January 9, 2024 21:07

AthenaCaesura added 2 commits January 9, 2024 17:00

fix: isort issues

3bbed10

fix: respond to PR comments

56c5946

max-radin requested changes Jan 19, 2024

View reviewed changes

AthenaCaesura added 2 commits January 24, 2024 10:17

fix: rename i<->e in heisenburg

49df9a6

fix: forgot to save on previous commit

1395fa7

max-radin self-requested a review January 24, 2024 16:02

max-radin approved these changes Jan 24, 2024

View reviewed changes

AthenaCaesura merged commit dd6b2a7 into main Jan 24, 2024
6 checks passed

AthenaCaesura deleted the DTA2-DTA2-255-consistent-naming branch January 24, 2024 21:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Dta2-255 consistent naming #139

Dta2-255 consistent naming #139

AthenaCaesura commented Nov 3, 2023

github-actions bot commented Nov 3, 2023 •

edited

Loading

mstechly commented Nov 14, 2023

AthenaCaesura commented Nov 14, 2023

max-radin Nov 14, 2023

pediejo Dec 8, 2023

max-radin Nov 14, 2023

AthenaCaesura Jan 8, 2024

max-radin Nov 14, 2023

AthenaCaesura Jan 8, 2024

max-radin Nov 16, 2023

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

max-radin commented Nov 16, 2023

pediejo left a comment

pediejo Dec 7, 2023

AthenaCaesura Jan 8, 2024

pediejo Dec 8, 2023

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

AthenaCaesura Jan 8, 2024

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

pediejo Dec 8, 2023

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

pediejo Dec 8, 2023

AthenaCaesura Jan 8, 2024

max-radin left a comment

Dta2-255 consistent naming #139

Dta2-255 consistent naming #139

Conversation

AthenaCaesura commented Nov 3, 2023

Description

Please verify that you have completed the following steps

github-actions bot commented Nov 3, 2023 • edited Loading

mstechly commented Nov 14, 2023

AthenaCaesura commented Nov 14, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

max-radin commented Nov 16, 2023

pediejo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

max-radin left a comment

Choose a reason for hiding this comment

github-actions bot commented Nov 3, 2023 •

edited

Loading