https://nf-co.re logo
Join Slack
Powered by
Finally cornered one of the more insidious bugs I'...
# mcmicro
a
Finally cornered one of the more insidious bugs I've hit in a while in nf-core/mcmicro. Multi-sample runs die in MCQUANT with "the number of channels in markers.csv doesn't match the image." It cost me a long detour before the real culprit turned up. For multi-sample runs, mcmicro 
collectFiles marker_name
across all samples into one shared 
markers.csv
(with no per-sample key) and hands that same frankensheet to every sample's 
MCQUANT
, so the marker count (64 in my run) never matches a single image's 44. Single-sample runs pass because there's only one sample's markers to pile up, which is also why it's slipped through: the test datasets are all single-sample. Fix is smallish: build the marker file per sample, keyed by 
meta.id
. I can make a PR
j
We have multi-sample runs in the test suite though. Can you provide a reproducer nf-test case?
These three are all 2-sample, 2-cycle configurations (we reuse one raw input file since we only have 3 unique raw files in the test-datasets repo)
Copy code
cycle: multiple file ashlar input with multiple samples no correction
cycle: multiple file ashlar input with multiple samples no correction, multiple segmentation
cycle: multiple file ashlar input with multiple samples and basicpy correction
The marker table flows through the pipeline as a single-value channel, where the value is a list-of-maps containing the entire table. There is no joining against the sample channel or anything like that so I'm not quite sure where this "frankensheet" is coming from.
The only manipulation we do on the version of the marker table we hand to mcquant is dropping rows marked with 
remove
if backsub is enabled (since backsub physically removes those channels from the stitched image).
Also the marker file is fixed, it doesn't vary by sample, so "build the marker file per sample, keyed by meta.id" doesn't seem to make sense?
Open in Slack
PreviousNext
Powered by