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

Breaking Overlap Controllers with RT Drift, then Correcting #202

Open
mcbrider5002 opened this issue Dec 14, 2020 · 6 comments
Open

Breaking Overlap Controllers with RT Drift, then Correcting #202

mcbrider5002 opened this issue Dec 14, 2020 · 6 comments
Labels
question Further information is requested

Comments

@mcbrider5002
Copy link
Collaborator

Currently we have multiple controllers that treat RoIs as boxes and use properties of overlap between these boxes for prioritisation. (e.g. Non-overlap controller uses the unique area of a box.) By adding RT drift to these controllers, they should cease to function properly because between injections the 'same' box will be shifted to a different location, and thus appear to be a different box. Therefore if our controllers are working as expected, we should expect the performance improvement of e.g. the non-overlap controller to degrade totally as we add more severe RT drift. (With enough drift that we can guarantee no boxes will overlap, we should see the same performance as TopN.)

Once we have established this, we can use a Gaussian Process model to learn f'(t), an estimate of the drift function f(t), as we run the controller, and shift the raw boxes by f'(t) during calculations to compensate for RT drift.

One potential issue we will have to address here: as our ability to correct for RT drift increases, we will fragment fewer of the same molecules, which means we will have fewer corresponding MS2 scans to learn from. Although we will have MS1 scans, these are often filled with noise or may otherwise change between injections, so this risks putting potentially incorrect training data into the GP.

@joewandy
Copy link
Member

Is this still a problem now? Any idea @mcbrider5002

@mcbrider5002
Copy link
Collaborator Author

Breaking non-overlap with drift has been done for a while: I'm still working on correcting drift. Correcting it (at least under the basic assumptions about the drift I have now, more complicated assumptions would likely lead to a deep rabbit-hole) will hopefully come to an end within the next couple of months.

@joewandy
Copy link
Member

Tidying up open issues. Can we close this @mcbrider5002 or shall we leave it open?

@mcbrider5002
Copy link
Collaborator Author

@joewandy It's been on the backburner for a while... Hoping to clean it up soon.

@joewandy
Copy link
Member

Can this be closed @mcbrider5002 ?

@joewandy joewandy added the question Further information is requested label Jan 31, 2023
@mcbrider5002
Copy link
Collaborator Author

@joewandy It hasn't moved forward (was working on other stuff). In theory I will get around to it at some point and it is probably useful to keep it open until someone does?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants