You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
this is mostly about continuous flow file calculations and could benefit from first having a clearer separation of classes between
dual_inlet
andcontinuous_flow
(maybe simply withdual_inlet
andcontinuous_flow
anddual_inlet_list
andcontinuous_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) viaiso_set_data/peak_table
and could adopt vendor data table to begin with usingiso_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
andpeak_table
together permanently onceiso_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 thepeak_table
from scratch (not implemented for now)iso_set_peak_table_from_vendor_data_table
: start with vendor data tableiso_set_peak_table
: set peak table from external information (or after calibration)iso_mutate_peak_table
: add new columns with useful informationiso_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 thepeak_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 wayiso_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.)The text was updated successfully, but these errors were encountered: