-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
Is this still a problem now? Any idea @mcbrider5002 |
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. |
Tidying up open issues. Can we close this @mcbrider5002 or shall we leave it open? |
@joewandy It's been on the backburner for a while... Hoping to clean it up soon. |
Can this be closed @mcbrider5002 ? |
@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? |
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.
The text was updated successfully, but these errors were encountered: