Skip to main content
Topic: Huge Retention Time differences in alignment at narrow retention time tolerance (Read 130 times) previous topic - next topic

Huge Retention Time differences in alignment at narrow retention time tolerance

Hey Everyone,

I have discovered something weird in the MS Dial tool and I am highly interested in your experiences with following issue:

 I used the retention time for alignment and the retention time tolerance was set to 0.075 min (4.5 seconds). Then the exported retention time matrix of the aligned peaks was checked for differences in retention time (min, max, range) and I have discovered that there were Peaks aligned which were several minutes apart. Please have a look to the screenshot of the export RT table: high_diff_in_RT.PNG. In the frist line I marked a peak which has a RT of 7.9 min and this was aligned with 5.9 min RT peaks... This is even worse than the statistical compare tool of LECO and I am very sceptical that this is the usual output. Has anyone experienced the same? Why should  set up a tolerance value if this is ignored by the aligning algorithm?!

Please have a look to your data and tell me if you have experienced similar results!

Kind Regards
Stefan

Re: Huge Retention Time differences in alignment at narrow retention time tolerance

Reply #1
Even though replying to one's own comments is like a one man show I would like to further comment on the problem I have described above  :D

The high difference in the RT of the aligned peaks is due to wrongly determined RI values, which I actually not even worked with. To my mind there are several error's in MS Dial I would like to report on:



Run 1:

In my MS Dial Analysis parameter setting I avoided using RI for Peak identification and peak alignment. Please have a look to the screenshots 4 and 5. Nevertheless MS-Dial requests for a RI dictionary (which is not needed in this case) by the end of the parameter setting menu and without uploading a file I could not start the analysis. This is shown in screenshot 6. So I uploaded a dictionary (even though my samples do not contain alkanes) and the analysis started. Keep in mind that I still had 'Use retention time' checked!

Results: There were just a few peaks aligned and the time axis of the Alignment spot viewer was displayed in RI (which were wrongly calculated). So MS Dial ignored my 'Use retention time' setting and still tried to align on RI basis. The wrong RI calculation is the reason why there were huge time differences in RT (because the wrong RI matched well).

Conclusion: MS Dial automatically selects RI alignment over RT, even though the user made a different selection. By the way I am also wondering why MS-Dial does the Gap filling automatically, even though I haven't selected this option (see screenshot 5.PNG and Gap_filling_but_unchecked.PNG).


Run 2:

2) After the first alignment I had a second look to the Analysis parameter setting (in the same project) and I switched back to 'Use retention time'. Then I ran the analysis for a second time. Now the Alignment Spot Viewer has the RT on the x axis an the aligned peaks were much closer since the algorithm really used the RT setting I made.




I am looking forward for responses and I also saw developers of MS Dial around. Please have a look to the issue I have described here.

Kind regards,

Stefan

Re: Huge Retention Time differences in alignment at narrow retention time tolerance

Reply #2
Dear Stefan,

sorry, I cannot reproduce your issue of RUN1.
After I choose "use retention time" in identification and alignment tabs, the program executes samples without the error messeage.

Hiroshi

Re: Huge Retention Time differences in alignment at narrow retention time tolerance

Reply #3
Dear Stefan,

sorry, I cannot reproduce your issue of RUN1.
After I choose "use retention time" in identification and alignment tabs, the program executes samples without the error messeage.

Hiroshi

Did you leave the Alkane Dictionary empty?

Stefan

Re: Huge Retention Time differences in alignment at narrow retention time tolerance

Reply #4
Yes->Stefan

Hiroshi