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

Improving T2 evaluation in Ramsey protocol #1034

Open
Edoardo-Pedicillo opened this issue Oct 29, 2024 · 3 comments
Open

Improving T2 evaluation in Ramsey protocol #1034

Edoardo-Pedicillo opened this issue Oct 29, 2024 · 3 comments

Comments

@Edoardo-Pedicillo
Copy link
Contributor

Edoardo-Pedicillo commented Oct 29, 2024

We can try to pre-process the data before doing the fit in order to choose whether we should perform an exponential fit or an exponential fit + sinusoidal term. On the top my head I'm thinking that we could do a FFT to detect if there is an oscillating term, if we find it we fit also with a sin if not we just fit with the exponential.

Originally posted by @andrea-pasquale in #1023 (comment)

@alecandido
Copy link
Member

I'm skeptical about this, since you need a fit to determine whether to make another fit. I.e., you will have to assess whether the FFT is identifying a peak well enough to be confident whether you need to apply a certain fit. And this is shifting the problem to identifying a peak in the FFT (even if you clip the low frequency modes, which is not always reliable).

As said in #1023 (comment), I'd consider it more promising to assess the success of a pure exponential fit, to decide whether to fallback on the other fit.

In any case, if anyone will take over this effort with a script, I'd avoid using the two routines, since it would trigger a double acquisition, and instead reprocess acquired data from the History in a second fit (which will be better supported with #1028, but it can be implemented even manually).

@Edoardo-Pedicillo
Copy link
Contributor Author

Edoardo-Pedicillo commented Oct 30, 2024

I'm skeptical about this, since you need a fit to determine whether to make another fit. I.e.,

This is something that we have already done with other fits, that are working quite well. Of course, the content of this PR is just a proposal and before being implemented in main should be tested.

@alecandido
Copy link
Member

This is something that we have already done with other fits, that are working quite well. Of course, the content of this PR is just a proposal and before being implemented in main should be tested.

I'm aware of the usage of FFT in (some) other fits, and that's what makes me dubious.
In the other fits, the critical difference is that you expect a sine, and the FFT is used just to estimate the initial point. Instead, here, you want to determine whether the oscillation is there or not.

Moreover, the FFT failed before, exactly because of the zero mode (which is very relevant here). @andrea-pasquale then solved the problem by cutting just the zero mode.
And there it was only a zero-mode (a constant), while here you know that you have a whole underlying function, so you will populate an entire band of low-frequency modes with the exponential decay.
If you are lucky, you can cut some, and remain with the exponential (but until you try to fit the exponential, you don't really know how much to cut), but sometimes the oscillation may be on frequencies that are still populated by the exponential, and finding you'd really need to find a peak (while in the other protocol a single maximum is taken). And this fit may also fail...

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

No branches or pull requests

2 participants