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

consider a data_table or peak_table df that carries with the isofiles #79

Closed
sebkopf opened this issue Oct 11, 2019 · 1 comment
Closed

Comments

@sebkopf
Copy link
Contributor

sebkopf commented Oct 11, 2019

this is mostly about continuous flow file calculations and could benefit from first having a clearer separation of classes between dual_inlet and continuous_flow (maybe simply with dual_inlet and continuous_flow and dual_inlet_list and continuous_flow_list) since they do behave quite differently for more complex operations (iso_calculate_deltas can then also be for dual inlet only and throw an error "doesn't make sense" for cf).

anyways, to simplify isoprocessor calculations that may benefit from staying in isofile space for plotting and other operations, it could be useful to introduce a data_table field that could be modified (e.g. if a calibrated peak table data set should be added back into the isofiles at a later point) via iso_set_data/peak_table and could adopt vendor data table to begin with using iso_set_peak_table_from_vendor_data_table (or something along those lines) and rename fields to names that are compatible with isoprocessor defaults (rt.s, rt_start.s, rt_end.s, etc., the likewise the areas and backgrounds).

this whole set of setting a peak_table could simply be a part of isoprocessor instead of isoreader to keep the separation of collecting data and using data crystal clear

the big question to solve is whether it makes more sense to keep the raw_data and peak_table together permanently once iso_set_data_table is called to simplify background and area calculations and plotting in continuous flow files or keep them separate and only combine as needed.

I would advocate for keeping them separate and only combining as needed even if that makes those operations a bit slower. I.e. an iso_calculate_peak_area combines the peak table and chromatogram and calculates areas, then spits out the peak table again into its own field and leaves the raw data unchanged. this would probably help from getting things too messy in where what data is stored.

the rough overview of functions would be:

  • iso_detect_peaks: peak detection that operates on the raw data and generate the peak_table from scratch (not implemented for now)
  • iso_set_peak_table_from_vendor_data_table: start with vendor data table
  • iso_set_peak_table: set peak table from external information (or after calibration)
  • iso_mutate_peak_table: add new columns with useful information
  • iso_map_peaks: modify the peak mapping function to work within the isofiles (to keep plotting easy)
  • iso_integrate_peaks: combine raw data with peak data to calculate peak areas, max peak height and store the result in the peak_data field - would need to simultaneously calculate backgrounds as well to pave the way for more complex background calculation procedures than just a fixed background (i.e. background area makes sense, background height would be at the apex rather than some sort of average)
  • iso_calculate_peak_ratios: calculate ratios in the peaks table, shouldn't need the raw data in any way
  • iso_calculate_peak_deltas: calculate peak deltas based on an expression that identifies the reference peaks to use, a delta value for the reference peaks (again an expression so it can be a fixed value or a column introduced from other information, by default 0 - somehow figure out how to do this taking the standard values into consideration too), and a method on how to extrapolate raw ratios from the ref peaks ("linear", "bracket", "average", etc.)
@sebkopf
Copy link
Contributor Author

sebkopf commented Oct 27, 2019

dual_inlet_list and continuous_flow_list classes introduced, rest is isorpocessor functionality --> moved to isoverse/isoprocessor#50

@sebkopf sebkopf closed this as completed Oct 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant