Hi Daria,

Thanks for including all the necessary files!

Looking at your .D files in SeeMS, there does not seem to be any MS2 data present. Perhaps there was some error in that translation step from Shimadzu data (I think that's what I'm looking at in "GCMS Data File Translation Log.txt")?

Thanks for using the Skyline support board,

Brian Pratt

Mike MacCoss reminds me:
"The data is from a single quad so there will be no MS2 data. The ionization is EI which causes fragmentation but those masses would have to be in the MS1 stage. So the user might want to extract multiple fragment ions but they would all be in the MS1 spectra as that is all there is."

I'm looking at this again. I believe we have handled this kind of data in the past.

Brian

OK, I think it is actually a data conversion problem - converting to mzML with msconvert I can see that there's not anything to indicate that it's EI data, so Skyline doesn't know it's supposed to look for fragments in the MS1 scans. Or nothing, at least, that msconvert recognizes. (Skyline uses the same underlying code as msconvert for reading .D, so Skyline doesn't see any EI hint either.)

If this isn't something addressable at the conversion stage, we can probably work out how to edit the mzML file to allow you to move forward.

Brian

Hello Brian,

Thank you for your quick response!

It can definitely be a conversion problem. This GC-MS data was collected using an Agilent GC-MS system with very old software (MSD ChemStation D.03.00.611). These files could not be read by Skyline at all. As a result, we tried converting them into several different formats: netCDF (Andi-MS), MassLynx, Shimadzu formats, and the newer MassHunter (XML) format. Among these, only the latter was readable by Skyline, and this is the format of the files I initially sent you.

Just in case, I’ve enclosed the original files from the instrument here. Perhaps you will have a better idea of which format would be best for converting the files.

Thank you very much for your help with this!

Best regards,
Daria

Interesting - what are you using for these various conversions?

I don't know anything about the .D format - we depend on the various instrument manufacturers to provide DLLs that handle those details. Near as I can tell, the information we need to know that a scan has EI fragmentation would normally be found in the not-human-readable MSScan.bin file.

Not terribly helpful, I'm afraid, but hopefully points you in the right direction if you have any control over the conversion step.

Brian

Hi Brian,

We have the exact same problem as Daria, and found no solution either. The trick with Pawel Sadowski's protocol for Shimadzu seems to be that Pawels setting make Skyline think it is reading MS2 in DIA mode although the data is actually MS1 EI data. For some reason, this works with Shimadzu but not with Agilent. But even if it works, we are somehow fooling Skyline to read the data the way we want.

Would it be possible to make reading MS1 EI data a new feature in Skyline? E.g. by adding an 'EI' option in the full scan settings menu, so that Skyline would know how to handle the data correctly?

Best,
Philipp

Hi Philipp,

From Skyline's internal data handling point of view, it's useful to treat EI as "MS2" since we think about "MS1" as measuring intact precursor ions, and MS2 as measuring their fragments. EI data is functionally similar to a "normal" mass spec file which omits any MS1 scans, so the term "MS2" is strictly speaking incorrect for EI but it's functionally useful when you think "fragment" instead of "MS2". We're unlikely to rework the Skyline interface to accommodate such generalist language but I expect we can at least make it easier for users to alert Skyline to EI usage.

I'd be interested to see your Skyline document and the data itself, I think that could inform the discussion about how to make this work more seamlessly.

Thanks for using the Skyline support board,

Brian

Hi Brian,

thank you for your quick response. I agree with you that EI data should be treated as "MS2" by Skyline although in the input files they are technically MS1. What we must achieve is that Skyline will read the MS1 data from the input files and, knowing that it is EI data, treat them as if it were MS2. This apparently works with the Shimadzu data but not with the Agilent data.

We dropped 'Agilent_EI_data.zip' in to the File Sharing Folder for Skyline Support. There is a Skyline document that demonstrates the issue: Agilent_EI_data.sky

The input files are:

20170612_PBQC_1.mzML – Shimadzu data from Pawel Sadowski’s tutorial (http://data.proteo.cloud/appendix5.pdf) as 'positive control'. The data can be read using the 'fake precursors' as well as the 'fragments as precursors' transition lists. Note that because we are using our transition list instead of Pawel's, other than the intended peaks are found.

2325012814.D – Agilent EI data. As Daria described, Skyline doesn’t recognize Chemstation’s .D so this was converted to MassHunter’s .D (containing XMLs) using Masshunter. Data from this file can only be displayed in Skyline using this 'fragments as precursors' molecule list. The features which are designed for MS2 data (e.g., some of the mProphet scores, library matches) won’t work in this way.

2325012814.mzML – converted from the above using MsConvert, gives the same result

2325012814_Frankenstein.mzML – Here we tried to provide the missing EI hint to Skyline by copying the instrument configuration from the Shimadzu .mzML over to our Agilent .mzML using a text editor (line 74-86). Skyline reads this chimeric file without error but still does not recognize it as EI.

Thanks so much for your help!

Best,
Philipp

Got the data, thanks.

We generally treat native data formats as a black box, and read them using DLLs supplied by the vendors.

But if we did go poking around in that .D folder, what artifact(s) in there say to you "yeah, this is EI data and certainly not anything else"?

That's tough. I believe it says nowhere explicitly. You can conclude from the presence of a file 'GC.ini' that this is GC data, and the human-readable information in 'acqmeth.txt' tells you this is GC-MS, but that's about it.

In the corresponding mzML file (generated by ProteoWizard msConvert), there is no indication whatsoever.

Maybe it would be best to tell Skyline manually that this should be treated as EI data? E.g. in the Transition Settings/Full Scan/MS MS Filtering one could have an option EI in addition to DIA, PRM, DDA. Then Skyline would know that all scans are to be read as MS2, regardless of how they are labelled.

You're probably right - we prefer to be as automagical as possible, but we also want to support mzML as completely as we do native formats, so adding a setting for EI data does seem like the way to. I'll put his into our development queue.

Could the same / a similar approach be useful for single-quadrupole LCMS instruments, where in-source ESI fragmentation is being exploited (on Agilent systems using the 'Fragmentor Voltage' setting for example)?
Many thanks folks
Jimmy

I should think so - could you provide a sample mass spec file and transition list for our development and test efforts?

Best regards,

Brian Pratt

I have just seen Skyline-daily 24.1.1.449 came out yesterday. Is the Agilent fix already in there?

Unfortunately not. I haven't begun work on that yet.

@Philipp - Do you have a transition list to go with the data you provided? That is, a normal one that you would expect to just work with Skyline if the "EI" option was available?

Hi Brian,

We now dropped '2025-03-28_Agilent_EI_data.zip' in to the File Sharing Folder for Skyline Support. There are the following files:

Transition List.xlsx
2325013014.D -> the Mass Hunter file for one samples
2325013014_original.mzXML -> converted from Mass Hunter using ProteoWizard MSconvert
2325013014_edited.mzXML -> the previous file, manually edited as described below
2325013014_no_fileName_tag.mzXML -> the previous file, manually edited in a different way
... plus a Skyline document in which the previous files are loaded

The 'Fake Precursors' molecule list in 'Transition List.xlsx' is in the format described by Pawel Sadowski and should work with Skyline once the "EI" option is available. In the present version of Skyline, it does NOT work with '2325013014.D' and '2325013014_original.mzXML'. Neither does it work with mzML files (not included here). Please note that the format described by Pawel Sadowski works with fake precursors that have arbitrary m/z values, but satisfy Skyline's requirement that every fragment must be associated with a precursor. A more radical approach would be to enable Skyline to read a transition list with only the product columns (without any precursor columns at all). This would be convenient, but not sure whether the internal data structures of Skyline would allow this.

We edited '2325013014_edited.mzXML' as described in the post https://skyline.ms/announcements/home/support/thread.view?rowId=57852 that we had missed earlier. The value in the <msIonisation> tag was changed from “Unknown” to “electron ionization”. In every scan, fake precursors were defined by inserting <precursorMz>1</precursorMz>. After doing both changes, this file can be read by the present version of Skyline in DIA mode as if the "EI" option was already available!

Also '2325013014_no_fileName_tag.mzXML' can be read by the present version of Skyline in DIA mode as if the "EI" option was already available, but is manually edited in a different way: the only change to the original file is that the fileName attribute was removed from both instances of the parentFile tag at the very beginning of the file. This was a chance finding, and the file is being read in a very strange way: Every other scan is being read as MS1 and as MS2 in an alternating fashion. You will see that if you pick a peak and zoom in very closely.

Thanks,
Philipp