-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement/bam2fastq #960
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed earlier today, we should consider accommodating cases in which the bam has the OQ
tag, so that we can get something as close to the original fastq as possible. This can be done with gatk's RevertSam
tool. We might have to first parse the input bam file to see if the OQ
tag is present, before running the tool. We should consider adding OQ
to our aligned bam outputs as well, which was brought up in #947
Yes. I think this can be done by first check if |
We need to bring this back to our radar. |
bam2fastq(inputBam) | ||
fastqs = bam2fastq.out.fastqOutput | ||
.map { idSample, targets, files_pe1, files_pe2 | ||
-> tuple(groupKey(idSample, files_pe1.size()), targets, files_pe1, files_pe2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fails with large bams that exceed the max int value. The type of files_pe1.size() would then be 'long' which is not able to be used by groupKey.
This might also be useful since we added #1008 and planning to just store BAMs instead of FASTQs.