# HG changeset patch # User iuc # Date 1638009518 0 # Node ID 82398ba86ba728c2fc587c63b221ced567b70f06 # Parent 4a53b89fa7035c99349c3b7577702f10486dd26f "planemo upload for repository https://github.com/galaxyproject/tools-iuc/tree/master/tools/velvetoptimiser commit 87fc41195cd9d05d431e8363c31898ce07369ed3" diff -r 4a53b89fa703 -r 82398ba86ba7 velvetoptimiser.xml --- a/velvetoptimiser.xml Wed Jan 13 15:31:18 2021 +0000 +++ b/velvetoptimiser.xml Sat Nov 27 10:38:38 2021 +0000 @@ -1,5 +1,8 @@ - + Automatically optimize Velvet assemblies + + velvetoptimiser + velvet perl-velvetoptimiser @@ -15,6 +18,7 @@ -t "\${GALAXY_SLOTS:-1}" -s $start_kmer -e $end_kmer + -x $kmer_step -d out -f " #for $i in $files: @@ -61,22 +65,26 @@ #end for " - ##if str($advanced.advanced_select) == "advanced" - $advanced.verbose - -k '$advanced.optFuncKmer' - -c '$advanced.optFuncCov' - #if str($advanced.velvetg_opts) != "" - -o '$advanced.velvetg_opts' - #end if - -m $advanced.minCutoff - -z $advanced.maxCutoff - ##end if + $advanced.verbose + -k '$advanced.optFuncKmer' + -c '$advanced.optFuncCov' + #if str($advanced.velvetg_opts) != "" + -o '$advanced.velvetg_opts' + #end if + -m $advanced.minCutoff + -z $advanced.maxCutoff ]]> - - - + + int(value) % 2 == 1 + + + int(value) % 2 == 1 + + + int(value) % 2 == 0 + @@ -108,12 +116,12 @@
- - - - - - + + + + + +
@@ -236,10 +244,12 @@ The hash length, also known as k-mer length, corresponds to the length, in base pairs, of the words being hashed. - The hash length is the length of the k-mers being entered in the hash table. Firstly, you must observe three technical constraints:: - - it must be an odd number, to avoid palindromes. If you put in an even number, Velvet will just decrement it and proceed. - - it must be below or equal to MAXKMERHASH length (cf. 2.3.3, by default 31bp), because it is stored on 64 bits - - it must be strictly inferior to read length, otherwise you simply will not observe any overlaps between reads, for obvious reasons. + The hash length is the length of the k-mers being entered in the hash table. Firstly, you must observe three technical constraints: + + - it must be an odd number, to avoid palindromes. If you put in an even number, Velvet will just decrement it and proceed. + - it must be below or equal to MAXKMERHASH length (cf. 2.3.3, by default 31bp), because it is stored on 64 bits + - it must be strictly inferior to read length, otherwise you simply will not observe any overlaps between reads, for obvious reasons. + Now you still have quite a lot of possibilities. As is often the case, it's a trade-off between specificity and sensitivity. Longer kmers bring you more specificity (i.e. less spurious overlaps) but lowers coverage (cf. below)... so there's a sweet spot to be found with time and experience. We like to think in terms of "k-mer coverage", i.e. how many times has a k-mer been seen among the reads. The relation between k-mer coverage Ck and standard (nucleotide-wise) coverage C is Ck = C * (L - k + 1)/L where k is your hash length, and L you read length. @@ -274,21 +284,15 @@ Velvet works mainly with fasta and fastq formats. For paired-end reads, the assumption is that each read is next to its mate read. In other words, if the reads are indexed from 0, then reads 0 and 1 are paired, 2 and 3, 4 and 5, etc. - Supported file formats are:: - - fasta - fastq - bam - - Read categories are:: + Supported file formats are: fasta, fastq, bam - short (default) - shortPaired - long (for Sanger, 454 or even reference sequences) - longPaired - reference (for pre-mapped sam or bam files - see Velvet manual for details on how to use this option) - - + Read categories are: + + - short (default) + - shortPaired + - long (for Sanger, 454 or even reference sequences) + - longPaired + - reference (for pre-mapped sam or bam files - see Velvet manual for details on how to use this option) ]]> @UNPUBLISHED{GLADMAN2012,