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
to simplify isoprocessor continuous flow calculations that may benefit from staying in isofile space for continuous flow plotting and other operations, it could be useful to introduce an peak_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, rt_start, rt_end, etc., and likewise the areas and backgrounds, + units via iso_double_with_units).
Calculation operations then operate on raw_data and peak_table (or often a combination of the two) as needed. I would advocate for keeping them separate rather than a hashed combined one 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, bgrd areas, bgrd_start height and bgrd_end height (depending on bgrd calculation modes), and store the result in the peak_data field
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 if provided by methods info), 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:
note iso_map_peaks is implemented inside the iso files but it is unclear whether this should become recommended best practice. A lot of downstream processing happens at this step that does not make sense to continue in the iso_files because it needs to unnecessary memory usage to make new variables.
to simplify isoprocessor continuous flow calculations that may benefit from staying in isofile space for continuous flow plotting and other operations, it could be useful to introduce an
peak_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
,rt_start
,rt_end
, etc., and likewise the areas and backgrounds, + units viaiso_double_with_units
).Calculation operations then operate on
raw_data
andpeak_table
(or often a combination of the two) as needed. I would advocate for keeping them separate rather than a hashed combined one even if that makes those operations a bit slower. I.e. aniso_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, bgrd areas, bgrd_start height and bgrd_end height (depending on bgrd calculation modes), and store the result in thepeak_data
fieldiso_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 if provided by methods info), 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: