Chunk wise data processing optimization
Curated, evidence-grounded skill and software-tool collections for scientific AI agents, generated by the AgenticScienceBuilder
npx -y skills add HolobiomicsLab/asb-skill-collections --skill chunk-wise-data-processing-optimizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when you have a large mass spectrometry dataset stored across multiple mzML, mzXML, or CDF files and need to perform operations (e.g., normalization, filtering, feature extraction) on the full dataset but memory constraints prevent loading all peak data simultaneously.
The file declares its own license as CC-BY-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
7.3 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
chunk-wise-data-processing-optimization
Summary
Split large MS datasets into memory-efficient chunks grouped by data source files, then process each chunk independently to reduce peak-data memory footprint while maintaining parallel processing capability. This skill applies the backendParallelFactor() method to enable lazy loading of m/z and intensity values on-the-fly rather than realizing all spectra into memory at once.
When to use
You have a large mass spectrometry dataset stored across multiple mzML, mzXML, or CDF files and need to perform operations (e.g., normalization, filtering, feature extraction) on the full dataset but memory constraints prevent loading all peak data simultaneously. Chunk-wise processing is indicated when your analysis workflow can tolerate sequential or batch processing of spectra groups without requiring global access to all peaks at once.
When NOT to use
- Your workflow requires simultaneous access to peak data from all spectra (e.g., global normalization across the entire dataset without reformulation for chunk-local processing)
- The dataset is already small enough to fit entirely in memory; chunk-wise processing adds overhead with minimal benefit
- You are using an in-memory backend such as MsBackendMemory or MsBackendDataFrame where all peak data is already loaded
Inputs
- MsBackendMzR object initialized with mzML, mzXML, or CDF files
- Spectra object with @backend slot containing file path metadata (dataStorage variable)
- Analysis function or workflow to apply to peak data
Outputs
- Processed Spectra object with reduced memory footprint
- Memory profile comparison report (whole-load vs. chunk-wise)
- Chunk grouping factor (Factor object mapping spectra to source files)
- List of peak data matrices (m/z and intensity pairs) for each chunk
How to apply
First, implement backendInitialize() to load MS data via MsBackendMzR and populate the dataStorage metadata variable with source file paths for each spectrum. Next, implement backendParallelFactor() to extract unique file paths from dataStorage and return a factor grouping spectra by their source file—this factor defines chunk boundaries. Implement peaksData() to extract m/z and intensity values on-the-fly as a list of matrices, supporting subsetting by index so only the current chunk's peak data is realized in memory. During processing, iterate over chunks grouped by the parallel factor, apply your analysis function to each chunk, and collect results. Finally, validate memory reduction by profiling peak-data memory usage under whole-load versus chunk-wise approaches and document the percentage reduction.
Related tools
- Spectra (Provides the S4 container class and virtual MsBackend API for defining chunk-aware data backends) — https://github.com/RforMassSpectrometry/Spectra
- MsBackendMzR (On-disk backend that retrieves peak data on-the-fly from raw MS files and implements backendParallelFactor() to enable file-based chunking) — https://github.com/RforMassSpectrometry/Spectra
- S4Vectors (Provides DataFrame and NumericList classes for storing spectra variables and peak data in the backend)
- mzR (Underlying package for reading mzML, mzXML, and CDF files in MsBackendMzR)
Examples
bpf <- backendParallelFactor(spectra@backend); chunks <- split(seq_along(spectra), bpf); for (i in seq_along(chunks)) { chunk_peaks <- peaksData(spectra@backend[chunks[[i]]]); result[[i]] <- processChunk(chunk_peaks) }
Evaluation signals
- backendParallelFactor() returns a factor with length equal to the number of spectra, with levels corresponding to unique source file paths
- peaksData() called on a chunk subset returns only the peak data for that chunk's spectra, not the entire dataset
- Memory usage profiling shows measurable reduction (e.g., >30%) when processing chunks compared to loading all spectra at once
- Processing results (e.g., feature tables, normalized intensities) are identical whether computed chunk-wise or in whole-load mode
- dataStorage variable correctly populated with file paths and matches the grouping structure defined by the parallel factor
Limitations
- Chunk-wise processing assumes independence of operations across file boundaries; global statistics or cross-file normalization require reformulation or additional aggregation steps
- Performance gains depend on efficient file I/O and disk caching; benefit diminishes if the same peaks are re-accessed across multiple chunks
- The parallel factor is tied to source file identity; datasets with many small files may yield many fine-grained chunks with higher overhead, while datasets with few large files yield fewer, larger chunks with less memory benefit
Evidence
- [other] MsBackendMzR's backendParallelFactor() returns a factor based on dataStorage file names to split the backend for parallel or serial processing.: "MsBackendMzR's backendParallelFactor() returns a factor based on dataStorage file names to split the backend for parallel or serial processing"
- [other] Chunk-wise processing via this splitting reduces memory demand because only the peak data of the current chunk—not all spectra—needs to be realized in memory during operations.: "Chunk-wise processing via this splitting reduces memory demand because only the peak data of the current chunk—not all spectra—needs to be realized in memory during operations"
- [readme] Backends such as the MsBackendMzR for example retrieve the data on the fly from the raw MS data files: "Backends such as the
MsBackendMzRfor example retrieve the data on the fly from the raw MS data files" - [intro] The peaksData() method extracts the MS peaks data from a backend, which includes the m/z and intensity values of each MS peak of a spectrum.: "The
peaksData()method extracts the MS peaks data from a backend, which includes the m/z and intensity values of each MS peak of a spectrum" - [intro] dataStorage and dataOrigin are two special spectra variables that define for each spectrum where the data is stored and from where the data derived: "
dataStorageanddataOriginare two special spectra variables that define for each spectrum where the data is stored and from where the data derived"
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.