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

Fragments are neither Hermitian nor anti-Hermitian #24

Open
max-radin opened this issue Nov 20, 2024 · 6 comments
Open

Fragments are neither Hermitian nor anti-Hermitian #24

max-radin opened this issue Nov 20, 2024 · 6 comments
Labels
bug Something isn't working low priority

Comments

@max-radin
Copy link
Contributor

When generating quantum resource estimates, many of the Hamiltonians (for example fcidump.41_1_ts_noncan_0.2_new.2f0b6ced-7831-4fe0-b95e-ce4d456c9c6b) give warnings about the double-factorized fragments being neither Hermitian nor anti-Hermitian. Based on discussion with @kjm538 this could potentially indicate a problem with the resource estimates. We should investigate this and make changes as needed.

/Users/maxradin/anaconda3/lib/python3.11/site-packages/pyLIQTR/ProblemInstances/ChemicalHamiltonian.py:130: UserWarning: Fragment 654 is neither Hermitian or anti-Hermitian!
  return DF_decomposition(h0, one_body_tensor, two_body_tensor,tol=sf_error_threshold)
@max-radin max-radin added the bug Something isn't working label Nov 20, 2024
@aakunitsa
Copy link
Contributor

Hi @max-radin, did the warning appear for a particular value of the sf_error_threshold? I couldn't reproduce it for id = 41 with the threshold of 1e-4.

@jp7745
Copy link
Member

jp7745 commented Dec 4, 2024

nohup.out.txt

I was running the LRE script and caught the error messages about fragments for a few associated Hamiltonians. See the attached log.

@max-radin
Copy link
Contributor Author

@aakunitsa I'm seeing the warning with sf_error_threshold set to 1e-12, which is the value currently used by the LRE script. However I don't get the warning when the threshold is set to 1e-4 or 1e-8. So it looks like it is only for certain values of the sf threshold.

sf_error_threshold=1e-12, # See https://github.com/isi-usc-edu/pyLIQTR/issues/21

@kjm538
Copy link

kjm538 commented Dec 5, 2024

@aakunitsa I'm seeing the warning with sf_error_threshold set to 1e-12, which is the value currently used by the LRE script. However I don't get the warning when the threshold is set to 1e-4 or 1e-8. So it looks like it is only for certain values of the sf threshold.

sf_error_threshold=1e-12, # See https://github.com/isi-usc-edu/pyLIQTR/issues/21

It sounds like this could be a precision issue. The relevant part of the pyLIQTR code is here:

https://github.com/isi-usc-edu/pyLIQTR/blob/c0760eab7363f6a1fd389cadc7b52b7dea06c1d9/src/pyLIQTR/utils/df_utils.py#L233-L243

where tiny=1e-12 by default. (and the input tol for this function is the sf_error_threshold).

@aakunitsa
Copy link
Contributor

Thank you for investigating @max-radin, @kjm538, and @jp7745! Do we have a sense of whether sf_error_threshold=1e-12 is really necessary? Now that I have the MPSs for all the coarse set instances from Josh, I can try to estimate the thresholds required for chemical accuracy and let you know what I find (especially since Max already made a script for that :))

@max-radin
Copy link
Contributor Author

max-radin commented Dec 12, 2024

Here's a table showing the effect of the sf threshold on LREs for blue_dimer (the problem instance which the Hamiltonian above belongs to). Decreasing the threshold from 1e-8 and 1e-12 increases the T count a bit (26% in the most extreme case). The increase in number of logical qubits however is negligible.

I think the fact that the higher threshold eliminates the warning message but still yields qualitatively similar estimates supports @kjm538's suggestion that this is just some sort of numerical precision issue. I would suggest that we downgrade this issue to low priority.

If/when we want to dig more into this, we could look at how far the fragments are from being (anti-)Hermitian, and also use MPS's to estimate the energy error incurred by sf truncation as @aakunitsa suggested. (I think this would require some modification of our old script though because right now I believe it only considers df truncation.)

Task UUID T gates (1e-12 threshold) T gates (1e-8 threshold) Logical qubits (1e-12 threshold) Logical qubits (1e-8 threshold)
9da97ef6-4bad-4c82-8576-9b8e539a7ba8 1916519744 1916519744 548 548
f20db1b1-86e3-4ddf-96ff-a6d37f331935 3131753792 3131753792 667 667
742be33c-0982-4b06-b324-1d86242e28d9 40376403840 33274267392 1040 1035
3b49563d-948a-4ecb-84a0-d3c0c2c0d217 46965131136 38051186560 1092 1092
950da653-13ce-4cd7-95d8-5045ab03d4bc 1920451904 1920451904 548 548
13821f5c-78a6-485c-9006-a17a234cde9f 3134768448 3134768448 667 667
765594e5-44ac-41a2-89a7-f2ac03536379 19790006024 16499246736 1039 1034
858b9683-fc6c-4ebe-8c33-27f0d848f24f 46641645440 37106812672 1092 1090
1a013e9f-7eab-4a1b-b486-1d9e2d99e754 2179253568 2171913536 590 590
001a0d11-165a-49c5-a334-643023029f40 11765450264 11047175704 845 845
1c9508e3-b9fe-44f1-ae58-c6339ef43f47 40271021952 33629210368 1040 1038
6713517a-ab65-4381-aae1-0839dcd6c1a0 47367784320 38470092672 1092 1092

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working low priority
Projects
None yet
Development

No branches or pull requests

4 participants