ions for GC?

[montmasis]

Hi, when we set the ionMode to either "pos" or "neg", does it always assume ions such as those formed by LC-ESI, i.e. [M+H]+ and [M-H]-?

Do you think it would it be possible to set parameters account for ions obtained by GC techniques, such as: electron impact ionization - positive [M]+ chemical ionization - positive MH+ chemical ionization - negative M- or [M-H]- ?

https://gulflink.health.mil/scud_ii/scud_ii_refs/n40en021/ci.html

Thanks!

Stefano

[skschum]

The following is pulled from my response to the other issue (#18) in order to put this directly related to question it is answering.

For the ion question, yes, pos and neg correspond only to standard protonation and deprotonation. However, you can do odd electron ionization ([M]+ and [M]-) if you add POEx = 1 (positive mode) or NOEx = 1 (negative mode) to your inputs (analogous to the heteroatoms). Currently MFAssignR only supports protonation/deprotonation, odd electron, and sodium adduct ionization mechanisms, though I will look into adding more types of ionization when I can.

Let me know if you have any additional questions, or if my answers are unclear. If you have any more problems, please let me know I and will try to address them as best I can.

Thanks, Simeon

[montmasis]

Thank you Simeon

Installation worked after I deleted old version of R, probably there were come conflicts of devtools.

Cool, I will try to add these ions and see how it goes. It would be great to include more ionizations/instruments in the future.

I tried at the moment an LC project (HRMS Orbital Q executive). The basic function worked very good. I am not completely sure on how to evaluate the SN cut off thresholds (by histogram and or KMD) and what cut off values to insert at the next step.

I am also having some troubles with the last part of the formula assignment after recalibrating the list.

Thanks for your help

Stefano

On Wed, Sep 23, 2020, 15:29 Simeon Schum notifications@github.com wrote:

The following is pulled from my response to the other issue (#18 https://github.com/skschum/MFAssignR/issues/18) in order to put this directly related to question it is answering.

For the ion question, yes, pos and neg correspond only to standard protonation and deprotonation. However, you can do odd electron ionization ([M]+ and [M]-) if you add POEx = 1 (positive mode) or NOEx = 1 (negative mode) to your inputs (analogous to the heteroatoms). Currently MFAssignR only supports protonation/deprotonation, odd electron, and sodium adduct ionization mechanisms, though I will look into adding more types of ionization when I can.

Let me know if you have any additional questions, or if my answers are unclear. If you have any more problems, please let me know I and will try to address them as best I can.

Thanks, Simeon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/skschum/MFAssignR/issues/19#issuecomment-697364989, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRG2CVXSWYJ4IHZY3QTXYTSHHZ45ANCNFSM4RW5OUTQ .

[skschum]

In the noise estimation functions, the estimated noise is reported which can then be used and multiplied by some value (often 3-6) to remove the noise peaks in the subsequent functions (IsoFiltR, MFAssign, etc.). To evaluate the ratio you want to use, you need to check how many peaks are removed and see if that seems appropriate. The SNPlot function can help visualize this. The use of SNPlot can be seen here: SNplot(Data, cut = SNRatio * KMDN, mass = 319.1, window.x = 0.2, window.y = 10).

The KMDNoise function is used as follows: Noise <-KMDNoise(Data, upper.y = 0.5, lower.y = 0.25) #Upper.y and lower.y can be changed as appropriate

This part shows how to extract the results of the KMDNoise() function so that they can be used

Noise[["KMD"]] #Plot showing the signal to noise estimation plot KMDN <-Noise[["Noise"]] #Saving the estimated noise as a global variable in the environment KMDN #Printing the noise so that you can see it in the final report. This is the estimated noise your can use in subsequent functions.

The subsequent functions have a "SN" parameter that can be set to SN = KMDN * 6, for example and all peaks below that intensity level will be removed. Let me know if this helps with regard to using the noise values.

What is the problem you are encountering with the final assignment after recalibration? There are some things that can go wrong, so I may be able to help if you can provide a bit more information.

Let me know if these answers help, or if you were asking a different question that I didn't answer.

Thanks, Simeon

[montmasis]

Thank you very much Simeon. I think it's clear regarding the noise level.

About the recalibration, I think there is some problem with one of the last tables, where the values in the experimental mass column looks more like the intensities (?) and thus the errors are huge. So maybe I am doing something wrong at some step.

Do you think we could discuss it via Zoom?

Thanks a lot!

Stefano

On Thu, Sep 24, 2020, 14:34 Simeon Schum notifications@github.com wrote:

In the noise estimation functions, the estimated noise is reported which can then be used and multiplied by some value (often 3-6) to remove the noise peaks in the subsequent functions (IsoFiltR, MFAssign, etc.). To evaluate the ratio you want to use, you need to check how many peaks are removed and see if that seems appropriate. The SNPlot function can help visualize this. The use of SNPlot can be seen here: SNplot(Data, cut = SNRatio * KMDN, mass = 319.1, window.x = 0.2, window.y = 10).

The KMDNoise function is used as follows: Noise <-KMDNoise(Data, upper.y = 0.5, lower.y = 0.25) #Upper.y and lower.y can be changed as appropriate

This part shows how to extract the results of the KMDNoise() function so

that they can be used Noise[["KMD"]] #Plot showing the signal to noise estimation plot KMDN <-Noise[["Noise"]] #Saving the estimated noise as a global variable in the environment KMDN #Printing the noise so that you can see it in the final report. This is the estimated noise your can use in subsequent functions.

The subsequent functions have a "SN" parameter that can be set to SN = KMDN * 6, for example and all peaks below that intensity level will be removed. Let me know if this helps with regard to using the noise values.

What is the problem you are encountering with the final assignment after recalibration? There are some things that can go wrong, so I may be able to help if you can provide a bit more information.

Let me know if these answers help, or if you were asking a different question that I didn't answer.

Thanks, Simeon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/skschum/MFAssignR/issues/19#issuecomment-698314742, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRG2CRECTMSYH2FX6FRR4LSHM4D5ANCNFSM4RW5OUTQ .

[skschum]

Yes, it is possible that the intensity and mass column are being switched at some point in your code. Assuming that you started with a dataframe with mass in column 1 and intensity in column 2, I would check the output after each function to make sure that the order is not being switched at some point. It shouldn't happen in any of the MFAssignR functions, but if it is it would be good to know. If you can confirm that the problem is a simple switching of the columns, then you can switch the columns around and try to assign the masses a formula at that point.

If you can't determine where the columns are being switched, or there is some other problem, let me know and we can set up a Zoom meeting.

Thanks, Simeon

[montmasis]

Hi! I did check the output of every step, and it looked it was alright till the very end after the calibration, and just swapped after MFAssign on the calibrated list (if I am not mistaken, I will check a third time). Yes a quick zoom would be great, if you have the availability. Thanks

Stefano

On Thu, Sep 24, 2020, 20:48 Simeon Schum notifications@github.com wrote:

Yes, it is possible that the intensity and mass column are being switched at some point in your code. Assuming that you started with a dataframe with mass in column 1 and intensity in column 2, I would check the output after each function to make sure that the order is not being switched at some point. It shouldn't happen in any of the MFAssignR functions, but if it is it would be good to know. If you can confirm that the problem is a simple switching of the columns, then you can switch the columns around and try to assign the masses a formula at that point.

If you can't determine where the columns are being switched, or there is some other problem, let me know and we can set up a Zoom meeting.

Thanks, Simeon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/skschum/MFAssignR/issues/19#issuecomment-698522835, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRG2CX2JDLWKNSOVBVUQ2TSHOIAXANCNFSM4RW5OUTQ .

[skschum]

I am available most of the time (including for the next hour or so). Let me know when you would like to have the meeting and we can do that.

Thanks, Simeon

[montmasis]

Hi, could we arrange for Monday next week? I live in Stockholm (EU), if you are at Pacific Northwest Institute in Seattle, that's 9 hours if I am correct. How about at 9 AM for you, 6 PM for me? Thanks a lot,

Stefano

On Thu, Sep 24, 2020, 22:08 Simeon Schum notifications@github.com wrote:

I am available most of the time (including for the next hour or so). Let me know when you would like to have the meeting and we can do that.

Thanks, Simeon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/skschum/MFAssignR/issues/19#issuecomment-698562262, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRG2CTUPPWTTJITNWK43HDSHORKPANCNFSM4RW5OUTQ .

[skschum]

Monday will work just fine. I am actually at Michigan Technological University, meaning I am in the Eastern US timezone, so only 6 hours behind you. We can still do 6 pm your time, or we can do it earlier as 9 AM is still fine for me. Let me know what you would like to do.

Thanks, Simeon

[montmasis]

Ah! Sorry, yes I got confused :) Yes then 9AM - 5PM would be perfect for me. Thanks! Do you get my other email in cc? (SciLifeLab)

Cheers

Stefano

On Fri, Sep 25, 2020, 14:07 Simeon Schum notifications@github.com wrote:

Monday will work just fine. I am actually at Michigan Technological University, meaning I am in the Eastern US timezone, so only 6 hours behind you. We can still do 6 pm your time, or we can do it earlier as 9 AM is still fine for me. Let me know what you would like to do.

Thanks, Simeon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/skschum/MFAssignR/issues/19#issuecomment-698892069, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRG2CWXDJA2EHS6ZO2SCD3SHSBZ7ANCNFSM4RW5OUTQ .