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

handle T2 > 2*T1 and clarify terminology #1994

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

dtmcclure
Copy link
Member

@dtmcclure dtmcclure commented Nov 8, 2023

Summary

  • replaces the NoiseError when T2 > 2*T1 with a warning and a line that caps T2 at the 2*T1 limit
  • clarifies some terminology issues i happened to notice while doing the above

Details and comments

Since T1 and T2 are typically measured at different times, it's not that uncommon for the most recently reported T2 to exceed the limit given by the most recently reported T1. Rather than treating this as an error, it seems better to just cap T2 at the physical limit and emit a warning.

While at it, I replaced some terms to clarify that T2 is the overall coherence time, not the relaxation time (T1) or the dephasing time (T_phi).

Since T1 and T2 are typically measured at different times, it's not that uncommon for the most recently reported T2 to exceed the most recently reported T1. Rather than treating this as an error, it seems better to just cap T2 at the physical limit and emit a warning.

While at it, I replaced some terms to clarify that T2 is the overall coherence time, not the relaxation time (T1) or the dephasing time (T_phi).
@hhorii hhorii requested a review from itoko November 9, 2023 00:39
@itoko
Copy link
Contributor

itoko commented Nov 22, 2023

Thanks, @dtmcclure (sorry for slow response). I'm all for improving terminology.
Also the upgrade in handling of T2 value makes sense to me.
In current API, callers of thermal_relaxation_error has responsibility to truncate T2 value and a private utility function _truncate_t2_value is provided. Raising errors in the case of T2 > 2 * T1 may be a bit beneficial (error-pruning) for users who provide T2 value by hand while the internal truncation (proposed in this PR) may be convenient for users who pass T2 values experimentally measured (not always need to write thermal_relaxation_error(t1, _truncate_t2_value(t1, t2), time)). I now lean to weight the latter benefit. I agree the change but it should be well documented.

Could you update docstring to mention the new spec (truncation of T2 to 2 * T1) and add a release note to tell the upgrade (raise an error -> silent truncation in the case of T2 > 2 * T1)?

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.

None yet

2 participants