comparison velvetoptimiser.xml @ 5:82398ba86ba7 draft default tip

"planemo upload for repository https://github.com/galaxyproject/tools-iuc/tree/master/tools/velvetoptimiser commit 87fc41195cd9d05d431e8363c31898ce07369ed3"

4:4a53b89fa703

<tool id="velvetoptimiser" name="VelvetOptimiser" version="2.2.6+galaxy1">
    <description>Automatically optimize Velvet assemblies</description>
    <requirements>
        <requirement type="package" version="1.2.10">velvet</requirement>
        <requirement type="package" version="2.2.6">perl-velvetoptimiser</requirement>
    </requirements>
    <version_command>VelvetOptimiser.pl --version</version_command>

        ## export OMP_THREAD_LIMIT=1 &&
        VelvetOptimiser.pl
            -t "\${GALAXY_SLOTS:-1}"
            -s $start_kmer
            -e $end_kmer
            -d out
            -f "
            #for $i in $files:
                -${i.filetype}

                    '$i.paired_type.input1'
                #end if
            #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

    ]]></command>
    <inputs>
        <param name="start_kmer" type="integer" value="31" label="Start k-mer size" help="Odd integer, Lower limit of k-mer size range to search for optimum value" />
        <param name="end_kmer" type="integer" value="191" label="End k-mer size" help="Odd integer, Upper limit of k-mer size range to search for optimum value" />
        <param name="kmer_step" type="integer" value="2" label="K-mer search step size" help="Even integer, the k-mer value step size when searching the range" />

        <repeat name="files" title="Input files" min="1">
            <param name="filetype" label="Input file type" type="select" help="Input file type">
                <option value="fastq">Fastq</option>
                <option value="fasta">Fasta</option>

                </when>
            </conditional>
        </repeat>

        <section name="advanced" title="Advanced Options" expanded="false">
            <param name="verbose" type="boolean" checked="false" truevalue="-v" falsevalue="" label="Verbose" help="Include verbose velvet output in log file" />
            <param name="optFuncKmer" type="text" value="n50" label="K-mer optimisation function" help="See help below for possibilities!"/>
            <param name="optFuncCov" type="text" value="Lbp" label="Coverage cutoff optimisation function" help="See help below for possibilities!"/>
            <param name="velvetg_opts" type="text" value="" label="Other velvetg options" help="Add any other required velvetg options from the advanced set"/>
            <param name="minCutoff" type="integer" value="0" label="Minimum coverage cutoff" help="The minimum coverage cutoff to consider in the optimisation"/>
            <param name="maxCutoff" type="float" value="0.8" label="Maximum coverage cutoff" help="The maximum coverage cutoff to consider expressed as a fraction of the calculated expected coverage."/>
        </section>
    </inputs>

    <outputs>
        <data format="fasta" name="contigs" label="${tool.name} on ${on_string}: Contigs" from_work_dir="out/contigs.fa"/>

      **Hash Length**

      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.

      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.
      Experience shows that this kmer coverage should be above 10 to start getting decent results. If Ck is above 20, you might be "wasting" coverage. Experience also shows that empirical tests with different values for k are not that costly to run! VelvetOptimiser automates these tests for you.

      **Input Files**

      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::

          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)


    ]]></help>
    <citations>
        <citation type="bibtex">@UNPUBLISHED{GLADMAN2012,
            author = "Gladman Simon",
            title = "VelvetOptimiser",

5:82398ba86ba7

<tool id="velvetoptimiser" name="VelvetOptimiser" version="2.2.6+galaxy2">
    <description>Automatically optimize Velvet assemblies</description>
    <xrefs>
        <xref type="bio.tools">velvetoptimiser</xref>
    </xrefs>
    <requirements>
        <requirement type="package" version="1.2.10">velvet</requirement>
        <requirement type="package" version="2.2.6">perl-velvetoptimiser</requirement>
    </requirements>
    <version_command>VelvetOptimiser.pl --version</version_command>

        ## export OMP_THREAD_LIMIT=1 &&
        VelvetOptimiser.pl
            -t "\${GALAXY_SLOTS:-1}"
            -s $start_kmer
            -e $end_kmer
            -x $kmer_step
            -d out
            -f "
            #for $i in $files:
                -${i.filetype}

                    '$i.paired_type.input1'
                #end if
            #end for
            "

            $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

    ]]></command>
    <inputs>
        <param name="start_kmer" argument="-s" type="integer" value="31"  min="11" max="191" label="Start k-mer size" help="Odd integer, Lower limit of k-mer size range to search for optimum value">
            <validator type="expression" message="Value needs to be odd">int(value) % 2 == 1</validator>
        </param>
        <param name="end_kmer" argument="-e" type="integer" value="191"  min="11" max="191" label="End k-mer size" help="Odd integer, Upper limit of k-mer size range to search for optimum value">
            <validator type="expression" message="Value needs to be odd">int(value) % 2 == 1</validator>
        </param>
        <param name="kmer_step" argument="-x" type="integer" value="2"  min="2" max="189" label="K-mer search step size" help="Even integer, the k-mer value step size when searching the range">
            <validator type="expression" message="Value needs to be even">int(value) % 2 == 0</validator>
        </param>

        <repeat name="files" title="Input files" min="1">
            <param name="filetype" label="Input file type" type="select" help="Input file type">
                <option value="fastq">Fastq</option>
                <option value="fasta">Fasta</option>

                </when>
            </conditional>
        </repeat>

        <section name="advanced" title="Advanced Options" expanded="false">
            <param name="verbose" argument="-v" type="boolean" checked="false" truevalue="-v" falsevalue="" label="Verbose" help="Include verbose velvet output in log file" />
            <param name="optFuncKmer" argument="-k" type="text" value="n50" label="K-mer optimisation function" help="See help below for possibilities!"/>
            <param name="optFuncCov" argument="-c" type="text" value="Lbp" label="Coverage cutoff optimisation function" help="See help below for possibilities!"/>
            <param name="velvetg_opts" argument="-o" type="text" value="" label="Other velvetg options" help="Add any other required velvetg options from the advanced set"/>
            <param name="minCutoff" argument="-m" type="integer" value="0" label="Minimum coverage cutoff" help="The minimum coverage cutoff to consider in the optimisation"/>
            <param name="maxCutoff" argument="-z" type="float" value="0.8" label="Maximum coverage cutoff" help="The maximum coverage cutoff to consider expressed as a fraction of the calculated expected coverage."/>
        </section>
    </inputs>

    <outputs>
        <data format="fasta" name="contigs" label="${tool.name} on ${on_string}: Contigs" from_work_dir="out/contigs.fa"/>

      **Hash Length**

      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.


      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.
      Experience shows that this kmer coverage should be above 10 to start getting decent results. If Ck is above 20, you might be "wasting" coverage. Experience also shows that empirical tests with different values for k are not that costly to run! VelvetOptimiser automates these tests for you.

      **Input Files**

      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: 
      
      - 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)
    ]]></help>
    <citations>
        <citation type="bibtex">@UNPUBLISHED{GLADMAN2012,
            author = "Gladman Simon",
            title = "VelvetOptimiser",