There appears to be an issue in the make_fastqs command when handling sample sheets with duplicated sample names that appear in different projects, for example:
1,PB1,PB1,,,A,C01,UDP0003V3,CGACATCCGA,UDP0003V3,AATGAACGTA,Project1
...
2,PB1,PB1,,,A,C01,UDP0003V3,CGACATCCGA,UDP0003V3,AATGAACGTA,Project2
...
In this case, the standard Fastq generation protocol (with no manual lane splitting) gives an error when using bcl2fastq as the BCL to Fastq converter:
ERROR: bcl2fastq::common::Exception: 2025-Feb-17 13:53:10: Success (0): bcl2fastq/src/cxx/lib/layout/Layout.cpp(650): Throw in function void bcl2fastq::layout::checkForDuplicateSample(const string&, const bcl2fastq::layout::SampleInfo&, const bcl2fastq::layout::SampleInfo&)
Dynamic exception type: N5boost16exception_detail10clone_implIN9bcl2fastq6common14InputDataErrorEEE
std::exception::what: Only 1 project is allowed for a given sampleId. SampleId: 'PB1'.
When using bcl-convert as the conversion software, if lanes are not manually split then there appears to be a bug in the Fastq merging step (at least if --no-lane-splitting is turned on), as reads appear to be incorrectly merged across projects for some Fastqs.
Manually splitting the lanes (e.g. auto_process.py make_fastqs --lanes=1:standard --lanes=2:standard) seems to avoid both these problems, so a longer term solution would appear to be to force splitting of lanes automatically in these cases.
There appears to be an issue in the
make_fastqscommand when handling sample sheets with duplicated sample names that appear in different projects, for example:In this case, the standard Fastq generation protocol (with no manual lane splitting) gives an error when using
bcl2fastqas the BCL to Fastq converter:Dynamic exception type: N5boost16exception_detail10clone_implIN9bcl2fastq6common14InputDataErrorEEE
std::exception::what: Only 1 project is allowed for a given sampleId. SampleId: 'PB1'.
When using
bcl-convertas the conversion software, if lanes are not manually split then there appears to be a bug in the Fastq merging step (at least if--no-lane-splittingis turned on), as reads appear to be incorrectly merged across projects for some Fastqs.Manually splitting the lanes (e.g.
auto_process.py make_fastqs --lanes=1:standard --lanes=2:standard) seems to avoid both these problems, so a longer term solution would appear to be to force splitting of lanes automatically in these cases.