I have tried both the official stable release (12.0) and the current alpha version (12.1), both on Windows 10, and the same/similar issues are true for both.
The first issue concerns how to control the thresholds for peak grouping across samples, and is related to this previous issue: https://github.com/ElucidataInc/ElMaven/issues/1351. There are two methods I see to limit what peaks are grouped--the "Minimum retention time difference between peaks in a group" in the "Peak Detection" tab in Settings, which as I understand acts as a hard cutoff, and the "Grouping Score" (its own tab), which I assume to be rank-based, i.e. a peak is grouped with whichever group gives the highest score.
As described in that previous issue, the hard cutoff seems to only take effect when the "Consider overlap" checkbox in the Grouping Score tab is NOT checked--which is counterintuitive since they seem to have nothing to do with one another. However, this hard cutoff is not SO useful as retention time drift is much larger for some groups (compounds) than others, and a cutoff strict enough to prevent grouping of a spurious but high-amplitude peak with one group is too strict to allow one or more other groups to be detected.
The grouping score would potentially be more useful, if it actually worked. However, changing the distX and Overlap weights doesn't seem to affect anything when running the peak detector (I have distY weighted at 0, since I don't want peak amplitude to influence it at all). I have noticed, however, that moving these sliders AFTER the peak detector has already run causes the grouping to update for the currently displayed group such that the correct peaks are grouped. The same, in fact, happens for the hard cutoff when the "Consider overlap" box is checked--it takes effect if you edit it or even press return in the field without editing--so it seems that the algorithm works correctly after the fact, yet not when the parameters are set ahead of time, which is odd.
This brings me to the other issue--though not ideal, I could work around the above by fiddling with parameters post hoc if I could somehow save the results--but as soon as I move to another peak in the peak table, all changes revert to what the automatic peak detection originally found. Even if I right-click on an entry in the peak table and select the "Edit peak group" option, then manually integrate the correct peaks, when I close that dialog box the changes are forgotten. And in fact, sometimes peaks that were found before are gone after this. In short, there is no way to force any changes made to the automatically found groups to "stick", no matter how I make the changes. This is very frustrating to say the least!
Have these bugs been fixed? If so, which version do I need to use to not have them be there?
I have tried both the official stable release (12.0) and the current alpha version (12.1), both on Windows 10, and the same/similar issues are true for both.
The first issue concerns how to control the thresholds for peak grouping across samples, and is related to this previous issue: https://github.com/ElucidataInc/ElMaven/issues/1351. There are two methods I see to limit what peaks are grouped--the "Minimum retention time difference between peaks in a group" in the "Peak Detection" tab in Settings, which as I understand acts as a hard cutoff, and the "Grouping Score" (its own tab), which I assume to be rank-based, i.e. a peak is grouped with whichever group gives the highest score.
As described in that previous issue, the hard cutoff seems to only take effect when the "Consider overlap" checkbox in the Grouping Score tab is NOT checked--which is counterintuitive since they seem to have nothing to do with one another. However, this hard cutoff is not SO useful as retention time drift is much larger for some groups (compounds) than others, and a cutoff strict enough to prevent grouping of a spurious but high-amplitude peak with one group is too strict to allow one or more other groups to be detected.
The grouping score would potentially be more useful, if it actually worked. However, changing the distX and Overlap weights doesn't seem to affect anything when running the peak detector (I have distY weighted at 0, since I don't want peak amplitude to influence it at all). I have noticed, however, that moving these sliders AFTER the peak detector has already run causes the grouping to update for the currently displayed group such that the correct peaks are grouped. The same, in fact, happens for the hard cutoff when the "Consider overlap" box is checked--it takes effect if you edit it or even press return in the field without editing--so it seems that the algorithm works correctly after the fact, yet not when the parameters are set ahead of time, which is odd.
This brings me to the other issue--though not ideal, I could work around the above by fiddling with parameters post hoc if I could somehow save the results--but as soon as I move to another peak in the peak table, all changes revert to what the automatic peak detection originally found. Even if I right-click on an entry in the peak table and select the "Edit peak group" option, then manually integrate the correct peaks, when I close that dialog box the changes are forgotten. And in fact, sometimes peaks that were found before are gone after this. In short, there is no way to force any changes made to the automatically found groups to "stick", no matter how I make the changes. This is very frustrating to say the least!
Have these bugs been fixed? If so, which version do I need to use to not have them be there?