All ions fragment scans should be MS1?

[sdrogers]

Been looking at real DIA data, e.g.: https://www.ebi.ac.uk/metabolights/MTBLS1572/files These are created in AIF mode (fragmenting everything). In the mzXML files, all scans are MS1, but every other one has been fragmented. Headers still say MS1. You can see a clear pattern in the output (look at intensities in following plot), and the scans themselves iterate between fragment and non-fragment.

At the moment, we cannot generate such data, but we need to be able to to make AIF like this.

Possible fixes:

1. Hack the MS-level of the MS2 scans back to MS1 when they get returned to the controller (feels mucky)
2. If a scan is passed to the simulator which has a collision energy >0 always return MS2 peaks and not MS1?

This is, I think, only a problem in the simulator. In the real MS, we can pass MS1 scans with collision energy and it will just fragment.

[sdrogers]

@RonanDaly this is the paper the data above is from -- do you think this looks an unusual setup? https://paperpile.com/shared/p8w5Lc

[kkto28]

Have done some changes/testings to align format of dia mzXML used in mentioned paper. Copy of code in simple_dia branch https://github.com/kkto28/vimms/commit/7acc2bd0dc40859f27a9e9a20102061bdd6e386f 1) test_controllers.py, using scan_time_dict = {1:0.124,2:0.124} instead of default 2) dia.py added post handling code to replace(hack) scan ms_level to one from two

Captured result is as following.

I am guessing Experimental_Information_ForAIF.txt can be used to differential level 1 or level 2 signals in tools. What I am trying is following configuration, while studying samples by using MSDial. ID MS Type Start m/z End m/z Name CE DecTarget(1:Yes, 0:no) 0 SCAN 65 1500 MS1 21 0 1 ALL 65 1500 MS2 45 1

Reference: https://mtbinfo-team.github.io/mtbinfo.github.io/MS-DIAL/tutorial#chapter-8

Been looking at real DIA data, e.g.: https://www.ebi.ac.uk/metabolights/MTBLS1572/files These are created in AIF mode (fragmenting everything). In the mzXML files, all scans are MS1, but every other one has been fragmented. Headers still say MS1. You can see a clear pattern in the output (look at intensities in following plot), and the scans themselves iterate between fragment and non-fragment.

At the moment, we cannot generate such data, but we need to be able to to make AIF like this.

Possible fixes:

1. Hack the MS-level of the MS2 scans back to MS1 when they get returned to the controller (feels mucky)
2. If a scan is passed to the simulator which has a collision energy >0 always return MS2 peaks and not MS1?

This is, I think, only a problem in the simulator. In the real MS, we can pass MS1 scans with collision energy and it will just fragment.

[sdrogers]

I think we've partly got to the bottom of this...

• DIA schemes sometimes use MS1 scans for frag, and sometimes MS2, probably depending on how the isolation window is determined (or if there is any isolation at all).
  • The current system works fine when the scans are sent as MS2 (simulator and real MS behave the same).
  • The sumulator currently cannot handle the situation of providing fragmentation data in an MS1 scan. Fixing this with a hack in the controller will only work in simulation. If we want to be able to use the same controllers in simulation and real MS we need to put the hack I the simulated MS.
  • Suggest that in the MS, we need to add an extra condition in this method: https://github.com/sdrogers/vimms/blob/3167584fc13d6338f6c8d7f7608c4c62f70a9540/vimms/MassSpec.py#L496 to check on the collision energy of the scan. If it is >0 we return MS2 data in an MS1 scan.

[sdrogers]

And a couple of further points of clarification:

• MS2 scans: these pick a precursor m/z and an isolation window. They also specify an m/z range over which to measure the fragment ions, i.e. where it should scan to and from.
• MS1 fragmentation scans: these specify and no isolation, just the collision energy and the m/z range over which to measure the fragment ions i.e. AIF: All ions fragmentation.