aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJustin Lecher <jlec@gentoo.org>2017-02-03 16:55:14 +0000
committerJustin Lecher <jlec@gentoo.org>2017-02-05 05:18:02 +0000
commite0bb430dd8c078ea0aa22268eba26a47febe7b31 (patch)
tree7415509e59998310159fb9ee307f5d1b70d3b4cf /sci-biology/blue
parentDrop all non *86 KEYWORDS (diff)
downloadsci-e0bb430dd8c078ea0aa22268eba26a47febe7b31.tar.gz
sci-e0bb430dd8c078ea0aa22268eba26a47febe7b31.tar.bz2
sci-e0bb430dd8c078ea0aa22268eba26a47febe7b31.zip
Drop all trailing whitespaces
Signed-off-by: Justin Lecher <jlec@gentoo.org>
Diffstat (limited to 'sci-biology/blue')
-rw-r--r--sci-biology/blue/blue-1.1.2.ebuild2
-rw-r--r--sci-biology/blue/blue-1.1.3.ebuild2
2 files changed, 2 insertions, 2 deletions
diff --git a/sci-biology/blue/blue-1.1.2.ebuild b/sci-biology/blue/blue-1.1.2.ebuild
index efb34809e..d8b8144a0 100644
--- a/sci-biology/blue/blue-1.1.2.ebuild
+++ b/sci-biology/blue/blue-1.1.2.ebuild
@@ -30,7 +30,7 @@ src_install(){
dobin Tessel.exe GenerateMerPairs.exe Blue.exe
# one could install also the *.exe.so files for speedup into /usr/bin/
- # The -hp option sets a flag that is checked when Blue is scanning along a read trying to find errors that could be corrected. There are a number of tests done at every base position, all based on depth of coverage. These tests will pick up random indel errors, but indels are so common at the end of homopolymer runs in 454 and IonTorrent data that multiple hp run lengths all look to be OK. For example, if our genome had AAAAAA then with Illumina data this is what we'd see almost all the time, with very rare indels at the end of the hp run resulting in runs of 5 or 7 As. With 454-like data, we'd probably get 5 As as frequently as 6 As so depth of coverage would say that neither of them are errors. The -hp flag looks out for the end of hp runs and forces an attempt at correction at that point. If the read wasn't in error, then no correction will be made.
+ # The -hp option sets a flag that is checked when Blue is scanning along a read trying to find errors that could be corrected. There are a number of tests done at every base position, all based on depth of coverage. These tests will pick up random indel errors, but indels are so common at the end of homopolymer runs in 454 and IonTorrent data that multiple hp run lengths all look to be OK. For example, if our genome had AAAAAA then with Illumina data this is what we'd see almost all the time, with very rare indels at the end of the hp run resulting in runs of 5 or 7 As. With 454-like data, we'd probably get 5 As as frequently as 6 As so depth of coverage would say that neither of them are errors. The -hp flag looks out for the end of hp runs and forces an attempt at correction at that point. If the read wasn't in error, then no correction will be made.
# In general Blue will correct Ns - if a correct replacement can be found. The only time it doesn't do this is if there are too many consecutive Ns - as the process of finding likely replacements is combinatoric and the cost goes up exponentially with the number of consecutive Ns. In these cases, the read is abandoned and passed through uncorrected. Can you give an example of a read that you would like to see corrected differently?
}
diff --git a/sci-biology/blue/blue-1.1.3.ebuild b/sci-biology/blue/blue-1.1.3.ebuild
index 59561cc13..dcdf67867 100644
--- a/sci-biology/blue/blue-1.1.3.ebuild
+++ b/sci-biology/blue/blue-1.1.3.ebuild
@@ -30,7 +30,7 @@ src_install(){
dobin Tessel.exe GenerateMerPairs.exe Blue.exe
# one could install also the *.exe.so files for speedup into /usr/bin/
- # The -hp option sets a flag that is checked when Blue is scanning along a read trying to find errors that could be corrected. There are a number of tests done at every base position, all based on depth of coverage. These tests will pick up random indel errors, but indels are so common at the end of homopolymer runs in 454 and IonTorrent data that multiple hp run lengths all look to be OK. For example, if our genome had AAAAAA then with Illumina data this is what we'd see almost all the time, with very rare indels at the end of the hp run resulting in runs of 5 or 7 As. With 454-like data, we'd probably get 5 As as frequently as 6 As so depth of coverage would say that neither of them are errors. The -hp flag looks out for the end of hp runs and forces an attempt at correction at that point. If the read wasn't in error, then no correction will be made.
+ # The -hp option sets a flag that is checked when Blue is scanning along a read trying to find errors that could be corrected. There are a number of tests done at every base position, all based on depth of coverage. These tests will pick up random indel errors, but indels are so common at the end of homopolymer runs in 454 and IonTorrent data that multiple hp run lengths all look to be OK. For example, if our genome had AAAAAA then with Illumina data this is what we'd see almost all the time, with very rare indels at the end of the hp run resulting in runs of 5 or 7 As. With 454-like data, we'd probably get 5 As as frequently as 6 As so depth of coverage would say that neither of them are errors. The -hp flag looks out for the end of hp runs and forces an attempt at correction at that point. If the read wasn't in error, then no correction will be made.
# In general Blue will correct Ns - if a correct replacement can be found. The only time it doesn't do this is if there are too many consecutive Ns - as the process of finding likely replacements is combinatoric and the cost goes up exponentially with the number of consecutive Ns. In these cases, the read is abandoned and passed through uncorrected. Can you give an example of a read that you would like to see corrected differently?
}