Let's begin with the basics - with ion mobility separation (IMS), we're using an ion's physical property of Collision Cross Section (CCS) as an additional separation dimension. IM is an effect of that physical property but is not itself an absolute. Different mass specs, and indeed potentially different runs on the same mass spec, use their own calibrations to translate between CCS and IM. CCS is the ground truth, an expression of a physical attribute of an ion, and IM is dependent on factors like gas pressure, temperature etc, as well as per-instrument peculiarities. So when Skyline uses an IM library, it's actually using the saved CCS values and asking the Bruker-provided API "for this data file, for an ion with this CCS, m/z and charge, what's the IM value we should filter on?". And the question really is particular to the individual data file, as the file carries its own calibration values. What's great about this is that we can also use that same CCS library to ask Agilent and Waters the same questions through the APIs they provide. CCS is a portable value but IM is not.
But how to get that ground truth CCS value? Increasingly there are CCS libraries available, or, Skyline can help create them by inspection. But that inspection approach is best done with very simple samples with confident identifications, such that RT separation already yields chromatograms with little or no interference and a peak in the IM dimension can only be due to one kind of ion. The CCS value associated with that IM value can then be re-used in mass spec runs with complex mixtures to pick apart interferences (and, as previously mentioned, can even be used in mass spec runs from completely different mass spec types and IMS technologies).
So when you think about it, deriving your ion mobility library based on complex mixtures instead of simple ones is missing the point of IMS. The peak in the IM dimension might be influenced by interference. And doing it on each individual mass spec run is even farther from the point of IMS.
Importing: Importing the same raw file with the same peptide/transition settings into separate skyline files produces A) peak area, RT, and spectral data and confident identifications or B) no peak areas or RT data displayed, unconfident identifications. I cannot figure out why this is happening.
It can be seen in your screenshots that the settings are not actually identical - the ion mobility libraries are differently named and presumably not identical. I'd have to see the mass spec files and the Skyline documents to offer deeper insights. If you care to provide those, use Skyline's File>Share>Complete menu item to create a .sky.zip file rather than sending just the .sky file.
Mobility filtering: The filtering window is frequently offset from observed maximum - is there a way to mediate this in skyline? When exporting a bruker method, how does skyline incorporate the mobility filtering? Is it necessary to refilter the data with the same library used in the method/data acquisition or should I use "Use Data" and refilter for a given dataset?
You can see by the purple band (a visual indicator of the IM band that will contribute to the chromatogram extraction) that IM filtering is excluding those signals, suggesting that either those peaks aren't associated with the ion of interest, or, if you are certain that they are, the library CCS value is incorrect.
Fundamentally, I suspect the issue here is that you have to do the groundwork (either with low-complexity samples or finding existing CCS libraries) to get realistic CCS values before you move on to complex samples.
I hope this helps, and do feel free to continue the conversation here.
Thanks for using the Skyline support board,