mirror of
https://github.com/metabarcoding/obitools4.git
synced 2026-11-10 01:24:41 +00:00
Complement to the documentation
Former-commit-id: 89952a6f3bb261a6aaec24430906e635914ffce4
This commit is contained in:
coissac committed
1 parent
eb351a7530
commit
03bef6461d
83 files changed
+65993
-10547
No files matched your search
Vendored
+14
-21
@@ -16,28 +16,28 @@
|
||||
{
|
||||
"objectID": "installation.html#availability-of-the-obitools",
|
||||
"href": "installation.html#availability-of-the-obitools",
|
||||
"title": "1 Installation of the obitools",
|
||||
"title": "1 Installation of the OBITools",
|
||||
"section": "1.1 Availability of the OBITools",
|
||||
"text": "1.1 Availability of the OBITools\nThe OBITools are open source and protected by the CeCILL 2.1 license.\nAll the sources of the OBITools4 can be downloaded from the metabarcoding git server (https://git.metabarcoding.org)."
|
||||
},
|
||||
{
|
||||
"objectID": "installation.html#prerequisites",
|
||||
"href": "installation.html#prerequisites",
|
||||
"title": "1 Installation of the obitools",
|
||||
"title": "1 Installation of the OBITools",
|
||||
"section": "1.2 Prerequisites",
|
||||
"text": "1.2 Prerequisites\nThe OBITools4 are developped using the GO programming language, we stick to the latest version of the language, today the \\(1.19.5\\). If you want to download and compile the sources yourself, you first need to install the corresponding compiler on your system. Some parts of the soft are also written in C, therefore a recent C compiler is also requested, GCC on Linux or Windows, the Developer Tools on Mac.\nWhatever the installation you decide for, you will have to ensure that a C compiler is available on your system."
|
||||
"text": "1.2 Prerequisites\nThe OBITools4 are developped using the GO programming language, we stick to the latest version of the language, today the \\(1.21.4\\). If you want to download and compile the sources yourself, you first need to install the corresponding compiler on your system. Some parts of the soft are also written in C, therefore a recent C compiler is also requested, GCC on Linux or Windows, the Developer Tools on Mac.\nWhatever the installation you decide for, you will have to ensure that a C compiler is available on your system."
|
||||
},
|
||||
{
|
||||
"objectID": "installation.html#installation-with-the-install-script",
|
||||
"href": "installation.html#installation-with-the-install-script",
|
||||
"title": "1 Installation of the obitools",
|
||||
"title": "1 Installation of the OBITools",
|
||||
"section": "1.3 Installation with the install script",
|
||||
"text": "1.3 Installation with the install script"
|
||||
"text": "1.3 Installation with the install script\nAn installation script that compiles the new OBITools on your Unix-like system is available online. The easiest way to run it is to copy and paste the following command into your terminal\n\ncurl -L https://metabarcoding.org/obitools4/install.sh | bash\n\nBy default, the script installs the OBITools commands and other associated files into the /usr/local directory. The names of the commands in the new OBITools4 are mostly identical to those in OBITools2. Therefore, installing the new OBITools may hide or delete the old ones. If you want both versions to be available on your system, the installation script offers two options:\n\n-i, –install-dir Directory where OBITools are installed (as example use /usr/local not /usr/local/bin).\n-p, –obitools-prefix Prefix added to the OBITools command names if you want to have several versions of obitools at the same time on your system (as example -p g will produce gobigrep command instead of obigrep).\n\nYou can use these options by following the installation command:\n\ncurl -L https://metabarcoding.org/obitools4/install.sh | \\\n bash -s -- --install-dir test_install --obitools-prefix k\n\nIn this case, the binaries will be installed in the test_install directory and all command names will be prefixed with the letter k. Thus obigrep will be named kobigrep."
|
||||
},
|
||||
{
|
||||
"objectID": "installation.html#compilation-from-sources",
|
||||
"href": "installation.html#compilation-from-sources",
|
||||
"title": "1 Installation of the obitools",
|
||||
"title": "1 Installation of the OBITools",
|
||||
"section": "1.4 Compilation from sources",
|
||||
"text": "1.4 Compilation from sources"
|
||||
},
|
||||
@@ -46,35 +46,28 @@
|
||||
"href": "formats.html",
|
||||
"title": "2 File formats usable with OBITools",
|
||||
"section": "",
|
||||
"text": "3 The DNA sequence data\nSequences can be stored following various format. OBITools knows some of them. The central formats for sequence files manipulated by OBITools scripts are the fasta and fastq format. OBITools extends the both these formats by specifying a syntax to include in the definition line data qualifying the sequence. All file formats use the IUPAC code for encoding nucleotides.\nMoreover these two formats that can be used as input and output formats, OBITools4 can read the following format :"
|
||||
"text": "3 The DNA sequence data\nSequences can be stored following various format. OBITools knows some of them. The central formats for sequence files manipulated by OBITools scripts are the FASTA and FASTQ format. OBITools extends the both these formats by specifying a syntax to include in the definition line data qualifying the sequence. All file formats use the IUPAC code for encoding nucleotides.\nMoreover these two formats that can be used as input and output formats, OBITools4 can read the following format :"
|
||||
},
|
||||
{
|
||||
"objectID": "formats.html#the-iupac-code",
|
||||
"href": "formats.html#the-iupac-code",
|
||||
"objectID": "formats.html#sec-iupac",
|
||||
"href": "formats.html#sec-iupac",
|
||||
"title": "2 File formats usable with OBITools",
|
||||
"section": "3.1 The IUPAC Code",
|
||||
"text": "3.1 The IUPAC Code\nThe International Union of Pure and Applied Chemistry (IUPAC_) defined the standard code for representing protein or DNA sequences.\n\n\n\nCode\nNucleotide\n\n\n\n\nA\nAdenine\n\n\nC\nCytosine\n\n\nG\nGuanine\n\n\nT\nThymine\n\n\nU\nUracil\n\n\nR\nPurine (A or G)\n\n\nY\nPyrimidine (C, T, or U)\n\n\nM\nC or A\n\n\nK\nT, U, or G\n\n\nW\nT, U, or A\n\n\nS\nC or G\n\n\nB\nC, T, U, or G (not A)\n\n\nD\nA, T, U, or G (not C)\n\n\nH\nA, T, U, or C (not G)\n\n\nV\nA, C, or G (not T, not U)\n\n\nN\nAny base (A, C, G, T, or U)"
|
||||
"text": "3.1 The IUPAC Code\nThe International Union of Pure and Applied Chemistry (IUPAC) defined the standard code for representing protein or DNA sequences.\n\n\n\nCode\nNucleotide\n\n\n\n\nA\nAdenine\n\n\nC\nCytosine\n\n\nG\nGuanine\n\n\nT\nThymine\n\n\nU\nUracil\n\n\nR\nPurine (A or G)\n\n\nY\nPyrimidine (C, T, or U)\n\n\nM\nC or A\n\n\nK\nT, U, or G\n\n\nW\nT, U, or A\n\n\nS\nC or G\n\n\nB\nC, T, U, or G (not A)\n\n\nD\nA, T, U, or G (not C)\n\n\nH\nA, T, U, or C (not G)\n\n\nV\nA, C, or G (not T, not U)\n\n\nN\nAny base (A, C, G, T, or U)"
|
||||
},
|
||||
{
|
||||
"objectID": "formats.html#sec-fasta",
|
||||
"href": "formats.html#sec-fasta",
|
||||
"title": "2 File formats usable with OBITools",
|
||||
"section": "3.2 The fasta sequence format",
|
||||
"text": "3.2 The fasta sequence format\nThe fasta format is certainly the most widely used sequence file format. This is certainly due to its great simplicity. It was originally created for the Lipman and Pearson FASTA program. OBITools use in more of the classical fasta format an extended version of this format where structured data are included in the title line.\nIn fasta format a sequence is represented by a title line beginning with a > character and the sequences by itself following the :doc:iupac code. The sequence is usually split other severals lines of the same length (expect for the last one)\n>my_sequence this is my pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\nThis is no special format for the title line excepting that this line should be unique. Usually the first word following the > character is considered as the sequence identifier. The end of the title line corresponding to a description of the sequence. Several sequences can be concatenated in a same file. The description of the next sequence is just pasted at the end of the record of the previous one\n>sequence_A this is my first pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\n>sequence_B this is my second pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\n>sequence_C this is my third pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT"
|
||||
"section": "3.2 The FASTA sequence format",
|
||||
"text": "3.2 The FASTA sequence format\nThe FASTA format is certainly the most widely used sequence file format. This is certainly due to its great simplicity. It was originally created for the Lipman and Pearson FASTA program. OBITools use in more of the classical FASTA format an extended version of this format where structured data are included in the title line.\nIn FASTA format a sequence is represented by a title line beginning with a > character and the sequences by itself following the IUPAC code. The sequence is usually split other severals lines of the same length (expect for the last one)\n>my_sequence this is my pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\nThis is no special format for the title line excepting that this line should be unique. Usually the first word following the > character is considered as the sequence identifier. The end of the title line corresponding to a description of the sequence. Several sequences can be concatenated in a same file. The description of the next sequence is just pasted at the end of the record of the previous one\n>sequence_A this is my first pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\n>sequence_B this is my second pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\n>sequence_C this is my third pretty sequence\nACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGT\nGTGCTGACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTACGTTGCAGTGTTT\nAACGACGTTGCAGTACGTTGCAGT\n\n3.2.1 File extensions\nThere is no standard file extension for a FASTA file, but .fa and .fasta, are commonly used."
|
||||
},
|
||||
{
|
||||
"objectID": "formats.html#sec-fastq",
|
||||
"href": "formats.html#sec-fastq",
|
||||
"title": "2 File formats usable with OBITools",
|
||||
"section": "3.3 The fastq sequence format1",
|
||||
"text": "3.3 The fastq sequence format1\nThe FASTQ format is a text file format for storing both biological sequences (only nucleic acid sequences) and the associated quality scores. The sequence and score are each encoded by a single ASCII character. This format was originally developed by the Wellcome Trust Sanger Institute to link a FASTA sequence file to the corresponding quality data, but has recently become the de facto standard for storing results from high-throughput sequencers (Cock et al. 2010).\nA fastq file normally uses four lines per sequence.\n\nLine 1 begins with a ‘@’ character and is followed by a sequence identifier and an optional description (like a :ref:fasta title line).\nLine 2 is the raw sequence letters.\nLine 3 begins with a ‘+’ character and is optionally followed by the same sequence identifier (and any description) again.\nLine 4 encodes the quality values for the sequence in Line 2, and must contain the same number of symbols as letters in the sequence.\n\nA fastq file containing a single sequence might look like this:\n@SEQ_ID\nGATTTGGGGTTCAAAGCAGTATCGATCAAATAGTAAATCCATTTGTTCAACTCACAGTTT\n+\n!''*((((***+))%%%++)(%%%%).1***-+*''))**55CCF>>>>>>CCCCCCC65\nThe character ‘!’ represents the lowest quality while ‘~’ is the highest. Here are the quality value characters in left-to-right increasing order of quality (ASCII):\n!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]\n^_`abcdefghijklmnopqrstuvwxyz{|}~\nThe original Sanger FASTQ files also allowed the sequence and quality strings to be wrapped (split over multiple lines), but this is generally discouraged as it can make parsing complicated due to the unfortunate choice of “@” and “+” as markers (these characters can also occur in the quality string).\n\nSequence quality scores\nThe Phred quality value Q is an integer mapping of p (i.e., the probability that the corresponding base call is incorrect). Two different equations have been in use. The first is the standard Sanger variant to assess reliability of a base call, otherwise known as Phred quality score:\n\\[\nQ_\\text{sanger} = -10 \\, \\log_{10} p\n\\]\nThe Solexa pipeline (i.e., the software delivered with the Illumina Genome Analyzer) earlier used a different mapping, encoding the odds \\(\\mathbf{p}/(1-\\mathbf{p})\\) instead of the probability \\(\\mathbf{p}\\):\n\\[\nQ_\\text{solexa-prior to v.1.3} = -10 \\; \\log_{10} \\frac{p}{1-p}\n\\]\nAlthough both mappings are asymptotically identical at higher quality values, they differ at lower quality levels (i.e., approximately \\(\\mathbf{p} > 0.05\\), or equivalently, \\(\\mathbf{Q} < 13\\)).\n\n\n\nFigure 3.1: Relationship between Q and p using the Sanger (red) and Solexa (black) equations (described above). The vertical dotted line indicates \\(\\mathbf{p}= 0.05\\), or equivalently, \\(Q = 13\\).\n\n\n\nEncoding\nThe fastq format had differente way of encoding the Phred quality score along the time. Here a breif history of these changes is presented.\n\nSanger format can encode a Phred quality score from 0 to 93 using ASCII 33 to 126 (although in raw read data the Phred quality score rarely exceeds 60, higher scores are possible in assemblies or read maps).\nSolexa/Illumina 1.0 format can encode a Solexa/Illumina quality score from -5 to 62 using ASCII 59 to 126 (although in raw read data Solexa scores from -5 to 40 only are expected)\nStarting with Illumina 1.3 and before Illumina 1.8, the format encoded a Phred quality score from 0 to 62 using ASCII 64 to 126 (although in raw read data Phred scores from 0 to 40 only are expected).\nStarting in Illumina 1.5 and before Illumina 1.8, the Phred scores 0 to 2 have a slightly different meaning. The values 0 and 1 are no longer used and the value 2, encoded by ASCII 66 “B”.\n\n\nSequencing Control Software, Version 2.6, (Catalog # SY-960-2601, Part # 15009921 Rev. A, November 2009, page 30) states the following: If a read ends with a segment of mostly low quality (Q15 or below), then all of the quality values in the segment are replaced with a value of 2 (encoded as the letter B in Illumina’s text-based encoding of quality scores)… This Q2 indicator does not predict a specific error rate, but rather indicates that a specific final portion of the read should not be used in further analyses. Also, the quality score encoded as “B” letter may occur internally within reads at least as late as pipeline version 1.6, as shown in the following example:\n\n@HWI-EAS209_0006_FC706VJ:5:58:5894:21141#ATCACG/1\nTTAATTGGTAAATAAATCTCCTAATAGCTTAGATNTTACCTTNNNNNNNNNNTAGTTTCTTGAGA\nTTTGTTGGGGGAGACATTTTTGTGATTGCCTTGAT\n+HWI-EAS209_0006_FC706VJ:5:58:5894:21141#ATCACG/1\nefcfffffcfeefffcffffffddf`feed]`]_Ba_^__[YBBBBBBBBBBRTT\\]][ dddd`\nddd^dddadd^BBBBBBBBBBBBBBBBBBBBBBBB\nAn alternative interpretation of this ASCII encoding has been proposed. Also, in Illumina runs using PhiX controls, the character ‘B’ was observed to represent an “uLine truncated
|
||||
},
|
||||
{
|
||||
"objectID": "formats.html#file-extension",
|
||||
"href": "formats.html#file-extension",
|
||||
"title": "2 File formats usable with OBITools",
|
||||
"section": "3.4 File extension",
|
||||
"text": "3.4 File extension\nThere is no standard file extension for a FASTQ file, but .fq and .fastq, are commonly used.\n\n\n\n\nCock, Peter JA, Christopher J Fields, Naohisa Goto, Michael L Heuer, and Peter M Rice. 2010. “The Sanger FASTQ File Format for Sequences with Quality Scores, and the Solexa/Illumina FASTQ Variants.” Nucleic Acids Research 38 (6): 1767–71."
|
||||
"section": "3.3 The FASTQ sequence format1",
|
||||
"text": "3.3 The FASTQ sequence format1\nThe FASTQ format is a text file format for storing both biological sequences (only nucleic acid sequences) and the associated sequence quality scores. Every nucleotide of the sequence and its associated quality score are each encoded by a single ASCII character. This format was originally developed by the Wellcome Trust Sanger Institute to link a FASTA sequence file to the corresponding quality data, but is now became the de facto standard for storing results from high-throughput sequencers (Cock et al. 2010).\nOBITools considers that a FASTQ file uses four lines per sequence.\n\nLine 1 begins with a ‘@’ character and is followed by a sequence identifier and an optional description (like a FASTA title line).\nLine 2 is the sequence letters, in upper or lower case, but OBITools only write sequences as lower cases.\nLine 3 begins with a ‘+’ character and is optionally followed by the same sequence identifier (and any description) again.\nLine 4 encodes the quality values for the sequence in Line 2, and must contain the same number of symbols as letters in the sequence.\n\nA FASTQ file looks like this:\n@SEQ_ID\nGATTTGGGGTTCAAAGCAGTATCGATCAAATAGTAAATCCATTTGTTCAACTCACAGTTT\n+\n!''*((((***+))%%%++)(%%%%).1***-+*''))**55CCF>>>>>>CCCCCCC65\nThe character ‘!’ represents the lowest quality while ‘~’ is the highest. Here are the quality value characters in left-to-right increasing order of quality (ASCII):\n!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]\n^_`abcdefghijklmnopqrstuvwxyz{|}~\nIf the original Sanger FASTQ files also allowed the sequence and quality strings to be wrapped (split over multiple lines), it is not supported by OBITools as it make parsing complicated due to the unfortunate choice of “@” and “+” as markers (these characters can also occur in the quality string).\n\nSequence quality scores\nThe Phred quality value Q is an integer mapping of p (i.e., the probability that the corresponding base call is incorrect). Two different equations have been in use. The first is the standard Sanger variant to assess reliability of a base call, otherwise known as Phred quality score:\n\\[\nQ_\\text{sanger} = -10 \\, \\log_{10} p\n\\]\nThe Solexa pipeline (i.e., the software delivered with the Illumina Genome Analyzer) earlier used a different mapping, encoding the odds \\(\\mathbf{p}/(1-\\mathbf{p})\\) instead of the probability \\(\\mathbf{p}\\):\n\\[\nQ_\\text{solexa-prior to v.1.3} = -10 \\; \\log_{10} \\frac{p}{1-p}\n\\]\nAlthough both mappings are asymptotically identical at higher quality values, they differ at lower quality levels (i.e., approximately \\(\\mathbf{p} > 0.05\\), or equivalently, \\(\\mathbf{Q} < 13\\)).\n\n\n\nFigure 3.1: Relationship between Q and p using the Sanger (red) and Solexa (black) equations (described above). The vertical dotted line indicates \\(\\mathbf{p}= 0.05\\), or equivalently, \\(Q = 13\\).\n\n\n\nEncoding\nThe FASTQ format had differente way of encoding the Phred quality score along the time. Here a breif history of these changes is presented. OBITools\n\nSanger format can encode a Phred quality score from 0 to 93 using ASCII 33 to 126 (although in raw read data the Phred quality score rarely exceeds 60, higher scores are possible in assemblies or read maps).\nSolexa/Illumina 1.0 format can encode a Solexa/Illumina quality score from -5 to 62 using ASCII 59 to 126 (although in raw read data Solexa scores from -5 to 40 only are expected)\nStarting with Illumina 1.3 and before Illumina 1.8, the format encoded a Phred quality score from 0 to 62 using ASCII 64 to 126 (although in raw read data Phred scores from 0 to 40 only are expected).\nStarting in Illumina 1.5 and before Illumina 1.8, the Phred scores 0 to 2 have a slightly different meaning. The values 0 and 1 are no longer used and the value 2, encoded by ASCII 66 “B”.\n\n\nSequencing Control Software, Version 2.6, (Catalog # SY-960-2601, Part # 15009921 Rev. A, November 2009, page 30) states the following: If a read ends with a segment of mostly low quality (Q15 or below), then all of the quality values in the segment are replaced with a value of 2 (encoded as the letter B in Illumina’s text-based encoding of quality scores)… This Q2 indicator does not predict a specific error rate, but rather indicates that a specific final portion of the read should not be used in further analyses. Also, the quality score encoded as “B” letter may occur internally within reads at least as late as pipeline version 1.6, as shown in the following example:\n\n@HWI-EAS209_0006_FC706VJ:5:58:5894:21141#ATCACG/1\nTTAATTGGTAAATAAATCTCCTAATAGCTTAGATNTTACCTTNNNNNNNNNNTAGTTTCTTGAGA\nTTTGTTGGGGGAGACATTTTTGTGATTGCCTTGAT\n+HWI-EAS209_0006_FC706VJ:5:58:5894:21141#ATCACG/1\nefcfffffcfeefffcffffffddf`feed]`]_Ba_^__[YBBBBBBBBBBRTT\\]][ dddd`\nddd^dddadd^BBBBBBBBBBBBBBBBBBBBBBBB\nAn alternative interpretation of this ASCII encoding has been proposed. ALine truncated
|
||||
},
|
||||
{
|
||||
"objectID": "tutorial.html#wolves-diet-based-on-dna-metabarcoding",
|
||||
|
||||
Reference in new issue
Block a user