You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ViMMS seems to have problems when scheduling fragmentation events below 80 m/z, even though defined constants would indicate the minimum should be 70 m/z. Fragmentation events between 70 and 80 m/z seem to be silently suppressed, though time does pass correctly between them. It's not currently clear at what stage this issue appears e.g. if the actual fragmentation event happens at all, or if it's a problem with writing to the .mzML, etc.
The above image shows a run of the intensity matching controller, which has many "unused" scans which must busy-wait, so they have been set to target some default value. In this case the default value is 100 m/z, so a line of fragmentation events can be clearly observed at 100 m/z.
This image shows the same run, but with the default target set to 75 m/z. No line of fragmentation events can be observed here, suggesting that these scans are dropped somehow.
In these images we see our picked peak boxes, i.e. our targets for the evaluation. Blue are fragmented: red unfragmented. At the bottom we see a clump of red (unfragmented) boxes below 80 m/z. This suggests that these cannot be targeted to cover them. The two controllers here are Intensity Non-Overlap and the intensity matching controller, which have little in common in their specific implementations, which suggests this may be a broader issue.
The text was updated successfully, but these errors were encountered:
Yes, it is. My workaround for it is that I've changed the MZMine parameters to not pick boxes below 80 m/z. But it still happens, and we don't know why it happens so it could cause us problems in future.
ViMMS seems to have problems when scheduling fragmentation events below 80 m/z, even though defined constants would indicate the minimum should be 70 m/z. Fragmentation events between 70 and 80 m/z seem to be silently suppressed, though time does pass correctly between them. It's not currently clear at what stage this issue appears e.g. if the actual fragmentation event happens at all, or if it's a problem with writing to the .mzML, etc.
The above image shows a run of the intensity matching controller, which has many "unused" scans which must busy-wait, so they have been set to target some default value. In this case the default value is 100 m/z, so a line of fragmentation events can be clearly observed at 100 m/z.
This image shows the same run, but with the default target set to 75 m/z. No line of fragmentation events can be observed here, suggesting that these scans are dropped somehow.
In these images we see our picked peak boxes, i.e. our targets for the evaluation. Blue are fragmented: red unfragmented. At the bottom we see a clump of red (unfragmented) boxes below 80 m/z. This suggests that these cannot be targeted to cover them. The two controllers here are Intensity Non-Overlap and the intensity matching controller, which have little in common in their specific implementations, which suggests this may be a broader issue.
The text was updated successfully, but these errors were encountered: