-
Notifications
You must be signed in to change notification settings - Fork 6
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
read component from IsoDat .dxf files #161
Comments
Are there plans for adding other kinds of data from the iso_get_vendor_data_table for IsoDat .dxf continuous flow files, such as peak areas? Or are they in an inconvenient data structure in .dxf files? |
Hi @jhowasmrtl , good idea for the component labels. Do you have a good example file to test this on? Component labels don't seem to get saved consistently so we couldn't figure out how to pull them out reliably but if we have more example files with and without component assignments we might be able to discern a more robust pattern to pull the information out. Peak areas are already in the vendor data table but they natively come out of isodat called
|
Yes, thank you! I’ve attached example .dxf files and also the exported data from IsoDat. These were produced with IsoDat version 3.0.94.12.
I may be able to script the peak definitions, but for data flow purposes (for now) it is best to use what’s produced by the software, as we always review the chromatograms in IsoDat prior to processing. I would love to use IsoProcessor for this in the future, especially given the ability to directly compare chromatograms.
Thanks for showing me where the area data is stored; yes it is very counterintuitive in its native heading! The changes to the headers in isoprocessor are perfect for this.
From: Sebastian Kopf ***@***.***>
Sent: Friday, April 9, 2021 9:55 PM
To: isoverse/isoreader ***@***.***>
Cc: John Howa ***@***.***>; Mention ***@***.***>
Subject: Re: [isoverse/isoreader] read component from IsoDat .dxf files (#161)
Hi @jhowasmrtl<https://github.com/jhowasmrtl> , good idea for the component labels. Do you have a good example file to test this on? Component labels don't seem to get saved consistently so we couldn't figure out how to pull them out reliably but if we have more example files with and without component assignments we might be able to discern a more robust pattern to pull the information out.
Peak areas are already in the vendor data table but they natively come out of isodat called rIntensityxx which I find very counterintuitive. The isoprocessor package provides some functionality to convert the peak table labels to more intuitive and shorter names, check out the example below:
library(isoreader)
library(isoprocessor)
iso_get_reader_example("continuous_flow_example.dxf") %>%
iso_read_continuous_flow() %>%
iso_set_peak_table_from_isodat_vendor_data_table() %>%
iso_get_peak_table()
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#161 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATIK4YI6DNA3W4O53XFEYEDTH7DZHANCNFSM4ZJNLATQ>.
|
I'm not overly familiar with GitHub, so I'm not sure if those files were made available to you via email attachments. I've made a repository with the files here |
great thank you! you can attach zip files to comments in issues on github but it doesnt seem it works from email |
implementation-in-progress note: Found a block in the binary dxf files that seem to contain the compound names list from the method. This is not directly associated with the peak table but should contain all the information necessary to match peaks with names (i.e. rt, window and min signal height). Unclear how to best do this automatically if there is ambiguity (isodat more or less ignores this problem). An example output looks like this (starts with the text block "Compound Names"):
Potential implementation approaches:
I'm more leaning towards the latter at the moment to keep the peak table pure of metadata and allow complete transparency in the workflow. |
In IsoDat 3, it is possible to assign a "component" label to peaks. This would be nice to read into the vendor_data_table.
The text was updated successfully, but these errors were encountered: