Imported seq summary histograms not matching sequence counts

Hi! The forum has many post that look like they would share my concern, but they were mostly about specific error messages or about the quality plots. My confusion is why the forward and reverse reads frequency histograms have incredibly low number of sequences (0.0-0.25) for most samples while the per-sample sequence counts shown below are higher. Albeit, many samples have very low counts (<10), but the x-axis being decimal places while all of the qiime tutorial graphs were in the hundreds or thousands has me stressing. What's going on?

demux_seqs.qzv (334.3 KB)

My next step is to de-noise, but I can't read this well enough to determine what to trim.

This is my workflow so far:

wget -r --level=10 -nH -nc --cut-dirs=3 --no-parent --reject "wget_index.html" --no-check-certificate --header "Cookie: sessionid=<session-id>;" <link-to-uc-davis-data>

qiime tools import 
--type 'SampleData[PairedEndSequencesWithQuality]' 
--input-path manifest 
--output-path demux_seqs.qza 
--input-format PairedEndFastqManifestPhred33V2

qiime demux summarize 
--i-data demux_seqs.qza 
--o-visualization demux_seqs.qzv

I'm doing my work in a kubernetes pod with the image "Quay".

Hey @kranderson,

Welcome to the forum!

It looks like the legend has chosen 1e7 as the base unit, which is odd, but matches your samples at least (so the bin is 0 through 2.5 million).

I'm a little more concerned as to why there's such bad read recruitment to your samples. I think this weird distribution is also why the histogram has such an unhelpful binning.

Is there any reason to think that your demultiplexing went awry? The quality of the reads themselves seem fine, so it looks to me like an index/barcode problem.

Thank you for correcting my reading of the x-axis! I suppose I’ll have to trim off the higher reads just to see a binning I can interpret with better spread.

As for the demiltiplexing, it wasn’t carried out by me. UC Davis demultiplexes before providing the data to their clients. Is there something else that could have failed?

At this point, not really, the demux is the first step.

Based on your provenance, it looks like you imported the samples directly and since we see them there's not much else that can be an issue.

If your samples are not especially low-biomass, I would ask your sequencing center as to why there were so few reads per sample. You might copy the table from the summary to show this (it really is quite unusually low, which is why neither of us have seen the matplotlib legend choose a unit like 1e7 before).

I would personally treat any further downstream processing with a pretty huge grain of salt since it kind of looks like these samples are "paired" in some way via the prefix, and the sequencing depth seems to be related in a mutually exclusive way between the pairs.

If your samples are not especially low-biomass, I would ask your sequencing center as to why there were so few reads per sample.

I had trouble extracting fungal DNA from these soil samples. While I was able to get okay (not great) amplification for most of them and pooled those in equimolar concentrations, some were so bad that my PI said that I should still add them to the pool but in minimal amounts. Does this explain the low counts, or should I still reach out to the UC Davis Genomics Core?

I would personally treat any further downstream processing with a pretty huge grain of salt since it kind of looks like these samples are "paired" in some way via the prefix, and the sequencing depth seems to be related in a mutually exclusive way between the pairs.

You're right, I have 12 sites from which there are 9 samples each (A-I or J-R). I sampled at two different time points (Jan=1 or July=7). So the sample name schema is SiteSampleTimepoint where 10A1 is site 10, sample A in January. I was going to look at diversity within sites, across sites (lumping together all samples within a site), and across time points