Hello!
I have a MiSeq dataset consisting of 33 samples/groups, of which 9 seem to have not enough or mainly bad sequences. While initating make.contigs, mothur tells me “xy.fastq has less than 8 good reads, skipping”. But instead of eliminating that 9 BAD samples/groups, the group count and the group file do not contain the LAST 9 samples/groups from my sample list, regardingless if they were good or not. Make sense? Is that supposed to be like that? Of course I could just delete the bad samples from my stability file, but I was wondering for the future. Many thanks!
Thanks for reporting this issue. It will be fixed in our next release. It effects the make.contigs command when the file option is used with a group provided, and one or more of the file pairs contain less good reads than the number of processors used. It is a rare case, thank you for helping us find it. There are two ways to work around this for your files. First you could remove the 9 bad samples, the files mothur is reporting “xy.fastq has less than 8 good reads, skipping”. Alternatively, you could run the command with processors=1.
Hello!
I think we have encountered the same or a very similar error in the current version of the ‘make.contigs’ command.
When any of the fastq files contains no reads, an error is correctly raised, but apparently the list of file/sample names is then treated differently than the list of the reads/read counts - consequently, the read counts are shifted: blank samples are wrongly assigned sequence counts, whereas real samples have wrong read counts.
The reason for blank positions being included in a run is a systematic testing of signal “leakage” between Illumina indices. Admittedly, this bug may of limited importance in real analyses.
Thank you,
Ondrej