-
Notifications
You must be signed in to change notification settings - Fork 19
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
Tons of warnings when using iTRAQ4plex or iTRAQ8plex #75
Comments
I see, this warning is indeed shown for isotopes. It will still count the atom, but not as an isotope (as far as I know for N and C this is not a problem, for deuterium it is a different issue). It would be possible to only display the same warning a single time, would that solve your issue? I still prefer to show the warning as this is the most transparent thing to do to the user. |
Showing the warning only once would be an improvement. I'm not sure I understand the current behaviour, though. If it's substituting isotopes, it will predict the same retention time for peptides that only differ by heavy and light SILAC labels, for example:
If they do indeed have the same observed retention time, why display the warning? And if they don't have the same retention time, surely DeepLC should try to predict the RT according to the isotope composition? |
Indeed is the only difference is a heavier isotope the predictions will be the same. While in most cases this is correct, for example in the case of deuterium it can create a difference in observed retention time. In your example it (should) not make a difference in observed retention time. Unfortunately, currently, DeepLC cannot account for different isotopes. It would take quite a bit of effort to change this. So for now we show a warning to indicate we cannot account for isotopes. |
If you use a modification like iTRAQ4plex or iTRAQ8plex, whose composition includes 13C or 15N, you get tons of warnings like:
This comes from FeatureExtrator.encode_atoms(). It has an argument
dict_index
whose default value doesn't have 13C or 15N. As far as I can tell, it's not possible to override the default from user code, as the only place where encode_atoms() is called is within FeatureExtractor itself.The text was updated successfully, but these errors were encountered: