Hi @Ricardo Fong Z! you are correct that nf-core/eager merges lanes before mapping. It is a decision we made back then to try and minimise the nuber of jobs being submitted to a scheduler, which I have since regretted a bit, as it causes trouble when working with deeper sequencing. 😞 One option would be to set each “lane” as its own library, and run eager ONLY for mapping. Then you can run a second eager run where you provide the BAM output of the first run as BAM input to the second, where you now use the correct library information, so deduplication works as intended. Another option, if you are not using production data(!), would be to use the edge version of nf-core/eager (

-r dev

) which has been completely reimplemented from scratch with additional functionality, including sharding of input FastQs to make mapping faster, as well as splitting by region during deduplication with subsequent merging (to achieve a similar optimisation for that step). We would particularly welcome a user testing the development version, but it does still lack some bits of functionality (specifically consensus calling, but also the MultiQC report that is generated is largely incomplete still), and the input TSV format has changed slightly from what is documented on the current version. 😃