mktrost
commented
11 years ago It was not something I was planning, but if it would be useful, it shouldn't be too difficult to add it.
Just a few questions (probably the hardest part of implementing it):
Would both ends as well as any unpaired reads (if any) all get written to 1 file in this case? Based on my quick read of the bwa page, I think this is a no. Would a user want the unpaired reads at all? Should there be an option to disable outputing unpaired reads?
Filename extension question: Typically the naming convention is: first in pair is outBase_1.fastq 2nd in pair is outBase_2.fastq unpaired in pair is outBase.fastq What would you want the naming convention to be for the interleaved file (if not written to stdout)?
I think that it makes sense to always write the first in pair first. The logic already supports this.
Would you like a flag, like --interleave? I'm open to flag name suggestions. Or would you rather just specify --firstOut & --secondOut to be the same filename? Either way should be easy enough to implement (and maybe both should be allowed).
I think for implementation, it would be checking the flag/filenames and if any are the same, then only call ifopen once and set the pointers, then only close once.
Thanks for the recommendation. Below I have some roughed out code that I am currently thinking might work. That way if I go to implement it later I remember what I am thinking now or if you want to implement it, you can see what I'm thinking.
Mary Kate
If you just do --firstOut - --secondOut - and add the following code, it might work
Instead of the current ifopen logic, use:
myUnpairedFile = ifopen(unpairedOut, "w");
if(myFirstFile == myUnpairedFile)
{
myFirstFile = myUnpairedFile;
}
else
{
myFirstFile = ifopen(firstOut, "w");
}
if(mySecondFile == myUnpairedFile)
{
mySecondFile = myUnpairedFile;
}
else if(mySecondFile == myFirstFile)
{
mySecondFile = myFirstFile;
}
else
{
mySecondFile = ifopen(secondOut, "w");
}Or if it never makes sense to interleave unpaired, then just check the first & second files against each other.
Then I'd make a closeFiles() method:
if((mySecondFile != myFirstFile) && (mySecondFile != myUnpairedFile) && (mySecondFile != NULL)) { ifclose(mySecondFile); mySecondFile = NULL; } if((myFirstFile != myUnpairedFile) && (mySecondFile != NULL)) { ifclose(myFirstFile); myFirstFile = NULL; } if(myUnpairedFile != NULL) { ifclose(myUnpairedFile); myUnpairedFile = NULL; }
Then call closeFiles() in the destructor and at the end of execute rather than manually closing each one.
On Fri, Sep 20, 2013 at 3:15 PM, Alex Lancaster notifications@github.comwrote:
Any chance of adding the option to bam2FastQ to generate an interleaved FASTQ file for paired-end reads? Currently it defaults to 2 FASTQ files. Some tools (e.g. bwa) will handle this form of data, e.g. the "-p" option for the "bwa mem" command (http://bio-bwa.sourceforge.net/bwa.shtml). It also makes it a lot easier to pipe the output from bam2FastQ directly into bwa without writing intermediate files. If it's not a feature that's currently planned, I'd be willing to look into what would be required to create a patch. Thanks!
— Reply to this email directly or view it on GitHubhttps://github.com/statgen/bamUtil/issues/10 .
alexlancaster
Any chance of adding the option to bam2FastQ to generate an interleaved FASTQ file for paired-end reads? Currently it defaults to 2 FASTQ files. Some tools (e.g. bwa) will handle this form of data, e.g. the "-p" option for the "bwa mem" command (http://bio-bwa.sourceforge.net/bwa.shtml). It also makes it a lot easier to pipe the output from bam2FastQ directly into bwa without writing intermediate files. If it's not a feature that's currently planned, I'd be willing to look into what would be required to create a patch. Thanks!