quality threshold

[Andrea Pappolla]

Hi everyone,

Probably I'm going to ask a "stupid" question but I'm new in NGS data analysis and in pear too.
I run the version 0.9.0
I set the quality threshold to a specified value (ex. 20 or 25 or...) to keep only the reads with good quality, but in my results the number of assembled reads are always the same whereas I think they would be less because of the trimming
Could you explain me where I'm wrong?

thanks.

ANdrea

[zhangjiajie]

Hi Andrea,

First please use the latest version from GitHub.
The trimming option is currently not implemented on the merged the reads, so you should get the same number of merged reads no matter how you change this parameter.
The default parameters are usually good enough for most of the data sets.
Hope this helps.


Best
Jiajie

--
You received this message because you are subscribed to the Google Groups "pear-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pear-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrea Pappolla]

Thank You very much for the answer Jiajie!

So the -q parameter works on reads not merged yet, right? but for example if I write

 "pear -f 16S_165bp1.fq -r 16S_165bp2.fq -o 16S_pear_q20 -q 20 -u 0" or
 "pear -f 16S_165bp1.fq -r 16S_165bp2.fq -o 16S_pear_q28 -q 28 -u 0
 I have the same number of assembled reads and I don't understand why.Also setting -q 35. I checked the results with fastqc tool and they are exactly the same

So please where do I find the latest version in GitHub?
thank you again

Andrea

[zhangjiajie]

Hi Andrea,

please find the up to date version here:
https://github.com/xflouris/PEAR

All quality controls were applied after the merge, not before, so the -q option will not work on the merged reads.

Best
Jiajie

[Andrea Pappolla]

Thank you again Jiajie!

These are the assembled reads with -q 20.. they don't look very well (attached)
Thanks

Andrea

[Tal Korem]

Hi Jiajie,

I didn't understand your answer exactly.

Does this mean the -q argument is useless?

Tal

[zhangjiajie]

Hi Tal,

The reason for trimming is because the lower quality base calls towards the end of a single end read, however, this does not exists for the merged the reads.
So the trimming is not implemented for the merged reads.

Further, the merging methods in PEAR already considered the quality scores when merging, so there is no need for trimming before merging.

The reason we kept this option is for case when people really want to use the single end reads that do not merge.



Jiajie

[Tal Korem]

Hi Jiajie, 

Thanks for clarifying. 

There could still be the case where a read would contain 2 consecutive bases with low quality, perhaps even not in the merged zone, and I would still want to discard it, wouldn't it?

Tal

[zhangjiajie]

Hi Tal,

Yes, we are considering to add a few more quality control options during this summer :)


Best

Jiajie

[Tal Korem]

Thanks Jiajie,

One last question - is it the same for the -u argument as well?

Tal