Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reading Intensities Correctly #22

Closed
zrolfs opened this issue Nov 27, 2023 · 6 comments
Closed

Reading Intensities Correctly #22

zrolfs opened this issue Nov 27, 2023 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@zrolfs
Copy link

zrolfs commented Nov 27, 2023

Hello! Thank you for this excellent repository. I'm trying to use read_chemstation_ch.R to read in a v179 .ch GC-FID file. The retention times seem right, but the intensities are very different from what I see when I open the file in MassHunter. Could there be an issue with the scaling factor that is applied?
I've attached the .ch (FID1A.txt) file as well as an excel where I compared the MassHunter and read_chemstation_ch intensities. Any help is appreciated!

image
image
image

FID1A.txt
Test.xlsx

@ethanbass
Copy link
Owner

ethanbass commented Nov 27, 2023

Hi zrolfs,
Thanks for pointing this out (and sharing your file)! There seem to be a couple of different issues at play here. The first is that there are at least two different types of chemstation 179 files. I was thinking that one was generated by openlab (and are accordingly marked "OL") while the other is generated by chemstation (and are marked "GC") but apparently this is not the case, which leaves me uncertain how to determine programmatically which type of 179 file is at hand. It seems that your file is the less common type, at least amongst the small subset of files i've been able to collect so far. I noticed that your file says "Mustang Chemstation" in the head (as does another one of my files which appears to (maybe?) be in the same format), while most of the other 179 files I have are from "Asterix Chemstation". I'm wondering if this could be a meaningful distinction as far as what type of 179 files are being produced.

The second issue is with the intensities. The intensities you plotted from masshunter appear to be uncorrected intensities (e.g. the uncorrected intensity at 4.49 minutes is 171572.7, compared to the 172000 you got from masshunter), but according to my understanding there's a scaling factor encoded in the file at byte 4732 (in this case 0.00013), so I'm not sure why the unscaled intensities are showing up in masshunter. I presume the data were originally collected in Chemstation. I don't suppose you would by any chance have access to the original Chemstation workstation to compare the values with the ones showing up in masshunter?

Here's a figure showing the uncorrected intensities:
image

and corrected intensities:
image

Ethan

@ethanbass
Copy link
Owner

ethanbass commented Nov 28, 2023

So I went ahead and opened your file in GC Chemstation (Rev. B.04.02 SP1 [212]) and it looks like the scaled version:

chemstation_fid

So I think MassHunter is wrong. Either that or there's a way to toggle the scaling of the y-axis and you may have it turned off.

If so, the only issue is to figure out how to determine programmatically which version a 179 file belongs to. I'm thinking of just going with my hypothesis that the "mustang chemstation" produces your style of file, but I don't really know if that's correct

@ethanbass
Copy link
Owner

ethanbass commented Nov 28, 2023

Hi @zrolfs. I tried to fix this on the dev branch by telling the parser to assume the "mustang" files are in the 8-byte format (like your file). Want to test it out for me? You should be able to install it by running remotes::install_github("ethanbass/chromConverter", ref="dev"). You'll likely need to reload your R session to purge the old version from your cache.

P.S.
Would you mind if I included your file in my chromConverterExtraTests package? It would be helpful to have a test file with your 8-byte format. I would be happy to attribute you of course.

@ethanbass ethanbass self-assigned this Nov 28, 2023
@ethanbass ethanbass added the bug Something isn't working label Nov 28, 2023
@ethanbass ethanbass mentioned this issue Nov 28, 2023
@zrolfs
Copy link
Author

zrolfs commented Dec 1, 2023

Hi Ethan,
Thanks for the quick response and your work on this! My wife gave birth between our messages, so I am going to be MIA for a bit. I should be back on January 2nd, but I've reached out to colleagues that might take a look at this for me in the meantime.

Quick thoughts:
-I agree with your finding; I think MassHunter is wrong, but at least proportional.
-Feel free to include the file; no attribution needed :)

@ethanbass
Copy link
Owner

ethanbass commented Dec 1, 2023

Congratulations!!!! hope you and the family have a nice holiday

@ethanbass
Copy link
Owner

Happy new year! I am closing this issue for now because my fix has been integrated into the main branch (a50105e) and I think everything is all working as it should. If you run into any additional issues, feel free to reopen.
Ethan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants