Report of Precursor Masses Without Identification of the resulting fragment

43 views
Skip to first unread message

Clemens Peiter

unread,
Sep 4, 2020, 10:39:23 AM9/4/20
to LipidXplorer discussion group

Dear all,

I have just come about an issue that I think might be a bug. It could also be that there is a command that I can use that I don't know about.

I am looking at fatty acid methyl esters. The problem is that the esters cannot be distinguished from the FA that are one C-atom longer, because they have exactly the same mass (e.g. FAME-17:0 and 18:0). Therefore, I fragment them in MS2, where I have a characteristic NL of C1 H4 O1.
Using LipidXplorer I was able to find the FAMEs. However, it also reports peak intensities, where there is actually no FAME, but only the FA that is one C-atom longer. I want to try and explain this with the following example:
I am looking for C17-FAME and C18-FAME. I have two samples. In one sample I added 17:0 in the other 18:0 and converted them to their methylesters. I measure both samples in MS1 and MS2. Then, I search for C17- and C18-FAMEs using LipidXplorer and find them in the corresponding samples (thanks to the characteristic fragmentation). In my report section, I report the intensity of the precursor peak in MS1, which leads to the following issue. I also find C17-FAME in the 18:0 sample. This is actually the 18:0 that is not a methylester (it has the same mass as the C17-FAME). I confirmed this by reporting the intensity of the fragment (in MS2) that results from the NL of C1 H4 O1. The intensity is 0 in the 18:0 sample.
I assume, LipidXplorer identifies the correct FAME in the 18:0 sample and the correct FAME in the 17:0 sample. It then goes to report the intensity of the precursor peaks at this mass. Unfortunately, the mass can also be found in the other sample and therefore it reports the intensity of the peak there.

I hope, this was comprehensible. So my question is: Is this a bug? Is it intended? Is there a workaround that I don't know about?
My workaround would be to just report the intensity of the fragment in MS2, by which I can identify, what is actually there and what isn't. Nevertheless, I think this could actually, very rarely, result in false positives.

Thank you in advance.
Clemens

Clemens Peiter

unread,
Sep 5, 2020, 10:49:37 AM9/5/20
to LipidXplorer discussion group
The mfql file I used is the following:
QUERYNAME = FAMESNL73;

DEFINE PR1 = 'C[23..28] H[45..55] O[2] N[4]' WITH DBR = (3.5,8), CHG = 1;
DEFINE PR2 = 'C[23..28] H[45..55] O[2] N[4]' WITH DBR = (3.5,8), CHG = 1;
DEFINE NL1 = 'C5 H15 O1 N1' WITH CHG = 0; #this NL includes the C1 H4 O1 plus an additional NL of C4 H11 N1 that all the precursors have

IDENTIFY
PR1 IN MS1+
AND PR2 IN MS2+
AND NL2 IN MS2+

SUCHTHAT
PR1.chemsc == PR2.chemsc

REPORT
NAME = "FAME [%d:%d]" % ((PR1.chemsc[C] - 9), (PR1.chemsc[db] - 3));
chemsc = PR1.chemsc;
MASS = "%4.4f" % "(PR1.mass)";
ERROR = "%2.2f ppm" % "(PR1.errppm)";
INT1 = PR1.intensity;
INTNL = NL1.intensity;
;

The output I receive:
The first reported signal intensity is the PR1.intensity, while the second one is the NL1.intensity. In each sample I fed cells with only one FA, i.e. 14:0, 15:0, 16:0,... As you can see, there is no signal of the NL1 for the 17:0 in the sample where I fed only 18:0. Therefore LipidXplorer could not have found a peak of the NL in MS2. Meaning that the signal seen for PR1.intensity does not come from the methylester. I think, the PR1.intensity in the 18:0-sample is reported, because it found a peak in the sample where I only fed 17:0 (i.e. the 17:0-FAME). The non-esterified 18:0 has the same mass as the esterified 17:0. I am 90% sure that this has nothing to do with my import or run settings. But if needed, I think I can provide them some other time.
Message has been deleted

Clemens Peiter

unread,
Sep 5, 2020, 10:54:57 AM9/5/20
to LipidXplorer discussion group
Somehow, I cannot upload the output file here. So I've uploaded it here: https://drive.google.com/file/d/1TZGuNIAg9_8JFnZ7ytukN7vK-VolIfvz/view?usp=sharing

Clemens Peiter schrieb am Samstag, 5. September 2020 um 16:50:59 UTC+2:
Reply all
Reply to author
Forward
0 new messages