Skip to content
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

Support for paired end reads #35

Open
brainstorm opened this issue Apr 2, 2013 · 9 comments
Open

Support for paired end reads #35

brainstorm opened this issue Apr 2, 2013 · 9 comments
Assignees

Comments

@brainstorm
Copy link
Collaborator

The same way fastq_screen (bowtie -1 -2...) supports. It is not efficient to read the two files sequentially (invoking FACS twice), it should be done at once in one single command.

Thanks @arvestad, @henrikstranneheim and @vals for the input.

@arvestad
Copy link
Contributor

This use case is now also supported by Daniel Lundin. He looked into using facs to screen rRNA, but this was a show-stopper.

@ghost ghost assigned tzcoolman Oct 26, 2013
@inodb
Copy link

inodb commented Nov 27, 2013

Hey! I'll have a look at this for Daniel Lundin if you guys don't have the time to fix this yourself. Any tips on things I should be aware of would be appreciated! I assume there's something tricky about this with the current implementation?

@brainstorm
Copy link
Collaborator Author

Ino, awesome to have you on board to have a look at this issue :D

The implementation itself is a bit tricky, yes, but if you just look at build.c and check.c you should be able to implement paired end support in it.

Feel free to make your own fork and pull request with your changes (code cleanups very welcome as well :)).

@inodb
Copy link

inodb commented Nov 27, 2013

Ok, thanks for the tips and the warm welcome!

@arvestad
Copy link
Contributor

I really appreciate it!

Lasse

On 27 Nov 2013, at 10:14, inodb [email protected] wrote:

Hey! I'll have a look at this for Daniel Lundin if you guys don't have the time to fix this yourself. Any tips on things I should be aware of would be appreciated! I assume there's something tricky about this with the current implementation?


Reply to this email directly or view it on GitHub.

@tzcoolman
Copy link
Contributor

I don't have a job now, so I can be supportive as much as possible @inodb

@henrikstranneheim
Copy link
Contributor

Nice to have you onboard Ino.

Cheers,
Henrik
On Nov 27, 2013, at 10:52 AM, inodb [email protected] wrote:

Ok, thanks for the tips and the warm welcome!


Reply to this email directly or view it on GitHub.

Henrik Stranneheim Ph.D.
Department of Molecular Medicine and Surgery
Karolinska Institute
Science for Life Laboratory, KISP
SE-171 65 Solna, Sweden

E-mail: [email protected]
Phone: +46 (0)8 524 81487 (Office)
Phone: +46 (0)736251487 (Mobile)
Visiting address: Tometebodavägen 23A

@ghost ghost assigned inodb Jan 12, 2014
@dbrami
Copy link

dbrami commented Sep 18, 2014

Hey folks,
I have no problem with running FACS twice but the issue is if one mate hits a contaminant then its mate should be marked as a contaminant as well. If not, then you are left with asynchronous paired fastq files.
Are there plans to address this as this is a showstopper for pre-assembly filtering.

@arvestad
Copy link
Contributor

It is on our to-do list, but we do not have a time plan for it.

Best,
Lars

On 18 Sep 2014, at 20:15, Daniel Brami [email protected] wrote:

Hey folks,
I have no problem with running FACS twice but the issue is if one mate hits a contaminant then its mate should be marked as a contaminant as well. If not, then you are left with asynchronous paired fastq files.
Are there plans to address this as this is a showstopper for pre-assembly filtering.


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants