obitools4/doc/_book/search.json

[
  {
    "objectID": "index.html",
    "href": "index.html",
    "title": "OBITools V4",
    "section": "",
    "text": "Preface\nThe first version of OBITools started to be developed in 2005. This was at the beginning of the DNA metabarcoding story at the Laboratoire d’Ecologie Alpine (LECA) in Grenoble. At that time, with Pierre Taberlet and François Pompanon, we were thinking about the potential of this new methodology under development. PIerre and François developed more the laboratory methods, while I was thinking more about the tools for analysing the sequences produced. Two ideas were behind this development. I wanted something modular, and something easy to extend. To achieve the first goal, I decided to implement obitools as a suite of unix commands mimicking the classic unix commands but dedicated to sequence files. The basic unix commands are very useful for automatically manipulating, parsing and editing text files. They work in flow, line by line on the input text. The result is a new text file that can be used as input for the next command. Such a design makes it possible to quickly develop a text processing pipeline by chaining simple elementary operations. The OBITools are the exact counterpart of these basic Unix commands, but the basic information they process is a sequence (potentially spanning several lines of text), not a single line of text. Most OBITools consume sequence files and produce sequence files. Thus, the principles of chaining and modularity are respected. In order to be able to easily extend the OBITools to keep up with our evolving ideas about processing DNA metabarcoding data, it was decided to develop them using an interpreted language: Python. Python 2, the version available at the time, allowed us to develop the OBITools efficiently. When parts of the algorithms were computationally demanding, they were implemented in C and linked to the Python code. Even though Python is not the most efficient language available, even though computers were not as powerful as they are today, the size of the data we could produce using 454 sequencers or early solexa machines was small enough to be processed in a reasonable time.\nThe first public version of obitools was OBITools2 (Boyer et al. 2016), this was actually a cleaned up and documented version of OBITools that had been running at LECA for years and was not really distributed except to a few collaborators. This is where OBITools started its public life from then on. The DNA metabarcoding spring schools provided and still provide user training every year. But OBITools2 soon suffered from two limitations: it was developed in Python2, which was increasingly abandoned in favour of Python3, and the data size kept increasing with the new illumina machines. Python’s intrinsic slowness coupled with the increasing size of the datasets made OBITools computation times increasingly long. The abandonment of all maintenance of Python2 by its developers also imposed the need for a new version of OBITools.\nOBITools3 was the first response to this crisis. Developed and maintained by Céline Mercier, OBITools3 attempted to address several limitations of OBITools2. It is a complete new code, mainly developed in Python3, with most of the lower layer code written in C for efficiency. OBITools3 has also abandoned text files for binary files for the same reason of efficiency. They have been replaced by a database structure that keeps track of every operation performed on the data.\nHere we present OBITools4 which can be seen as a return to the origins of OBITools. While OBITools3 offered traceability of analyses, which is in line with the concept of open science, and faster execution, OBITools2 was more versatile and not only usable for the analysis of DNA metabarcoding data. OBITools4 is the third full implementation of OBITools. The idea behind this new version is to go back to the original design of OBITools which ran on text files containing sequences, like the classic Unix commands, but running at least as fast as OBITools3 and taking advantage of the multicore architecture of all modern laptops. For this, the idea of relying on an interpreted language was 
  },
  {
    "objectID": "intro.html#aims-of-obitools",
    "href": "intro.html#aims-of-obitools",
    "title": "1  The OBITools",
    "section": "1.1 Aims of OBITools",
    "text": "1.1 Aims of OBITools"
  },
  {
    "objectID": "intro.html#file-formats-usable-with-obitools",
    "href": "intro.html#file-formats-usable-with-obitools",
    "title": "1  The OBITools",
    "section": "1.2 File formats usable with OBITools",
    "text": "1.2 File formats usable with OBITools\n\n1.2.1 The sequence files\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.\n\n\n1.2.2 The IUPAC Code\nThe International Union of Pure and Applied Chemistry (IUPAC_) defined the standard code for representing protein or DNA sequences.\n\n1.2.2.1 Nucleic IUPAC Code\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)\n\n\n\n\n\n\n1.2.3 The fasta 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 :ref:fasta format an :ref: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\n\n\n1.2.4 The fastq sequence format1\nfastq format is a text-based format for storing both a biological sequence (usually nucleotide sequence) and its corresponding quality scores. Both the sequence letter and quality score are encoded with a single ASCII character for brevity. It was originally developed at the Wellcome Trust Sanger Institute to bundle a fasta sequence and its quality data, but has recently become the de facto standard for storing the output of high throughput sequencing instruments such as the Illumina Genome Analyzer Illumina (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>>>
  },
  {
    "objectID": "intro.html#file-extension",
    "href": "intro.html#file-extension",
    "title": "1  The OBITools",
    "section": "1.3 File extension",
    "text": "1.3 File extension\nThere is no standard file extension for a FASTQ file, but .fq and .fastq, are commonly used."
  },
  {
    "objectID": "intro.html#see-also",
    "href": "intro.html#see-also",
    "title": "1  The OBITools",
    "section": "1.4 See also",
    "text": "1.4 See also\n\n:ref:fasta"
  },
  {
    "objectID": "intro.html#references",
    "href": "intro.html#references",
    "title": "1  The OBITools",
    "section": "1.5 References",
    "text": "1.5 References\n.. [1] Cock et al (2009) The Sanger FASTQ file format for sequences with quality scores, and the Solexa/Illumina FASTQ variants. Nucleic Acids Research,\n.. [2] Illumina Quality Scores, Tobias Mann, Bioinformatics, San Diego, Illumina 1__\n.. |Relationship between Q and p using the Sanger (red) and Solexa (black) equations (described above). The vertical dotted line indicates p = 0.05, or equivalently, Q Å 13.| image:: Probability metrics.png\nSee http://en.wikipedia.org/wiki/FASTQ_format\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."
  },
  {
    "objectID": "tutorial.html#wolves-diet-based-on-dna-metabarcoding",
    "href": "tutorial.html#wolves-diet-based-on-dna-metabarcoding",
    "title": "2  OBITools V4 Tutorial",
    "section": "2.1 Wolves’ diet based on DNA metabarcoding",
    "text": "2.1 Wolves’ diet based on DNA metabarcoding\nThe data used in this tutorial correspond to the analysis of four wolf scats, using the protocol published in Shehzad et al. (2012) for assessing carnivore diet. After extracting DNA from the faeces, the DNA amplifications were carried out using the primers TTAGATACCCCACTATGC and TAGAACAGGCTCCTCTAG amplifiying the 12S-V5 region (Riaz et al. 2011), together with a wolf blocking oligonucleotide.\nThe complete data set can be downloaded here: the tutorial dataset\nOnce the data file is downloaded, using a UNIX terminal unarchive the data from the tgz file.\n\ntar zxvf wolf_diet.tgz\n\nThat command create a new directory named wolf_data containing every required data files:\n\nfastq <fastq> files resulting of aGA IIx (Illumina) paired-end (2 x 108 bp) sequencing assay of DNA extracted and amplified from four wolf faeces:\n\nwolf_F.fastq\nwolf_R.fastq\n\nthe file describing the primers and tags used for all samples sequenced:\n\nwolf_diet_ngsfilter.txt The tags correspond to short and specific sequences added on the 5' end of each primer to distinguish the different samples\n\nthe file containing the reference database in a fasta format:\n\ndb_v05_r117.fasta This reference database has been extracted from the release 117 of EMBL using obipcr\n\n\n\n\n\nTo not mix raw data and processed data a new directory called results is created.\n\nmkdir results"
  },
  {
    "objectID": "tutorial.html#step-by-step-analysis",
    "href": "tutorial.html#step-by-step-analysis",
    "title": "2  OBITools V4 Tutorial",
    "section": "2.2 Step by step analysis",
    "text": "2.2 Step by step analysis\n\n2.2.1 Recover full sequence reads from forward and reverse partial reads\nWhen using the result of a paired-end sequencing assay with supposedly overlapping forward and reverse reads, the first step is to recover the assembled sequence.\nThe forward and reverse reads of the same fragment are at the same line position in the two fastq files obtained after sequencing. Based on these two files, the assembly of the forward and reverse reads is done with the obipairing utility that aligns the two reads and returns the reconstructed sequence.\nIn our case, the command is:\n\nobipairing --min-identity=0.8 \\\n           --min-overlap=10 \\\n           -F wolf_data/wolf_F.fastq \\\n           -R wolf_data/wolf_R.fastq \\\n           > results/wolf.fastq \n\nThe --min-identity and --min-overlap options allow discarding sequences with low alignment quality. If after the aligment, the overlaping parts of the reads is shorter than 10 base pairs or the similarity over this aligned region is below 80% of identity, in the output file, the forward and reverse reads are not aligned but concatenated, and the value of the mode attribute in the sequence header is set to joined instead of alignment.\n\n\n2.2.2 Remove unaligned sequence records\nUnaligned sequences (:pymode=joined) cannot be used. The following command allows removing them from the dataset:\n\nobigrep -p 'annotations.mode != \"join\"' \\\n        results/wolf.fastq > results/wolf.ali.fastq\n\nThe -p requires a go like expression. annotations.mode != \"join\" means that if the value of the mode annotation of a sequence is different from join, the corresponding sequence record will be kept.\nThe first sequence record of wolf.ali.fastq can be obtained using the following command line:\n\nhead -n 4 results/wolf.ali.fastq\n\nThe folling piece of code appears on thew window of tour terminal.\n@HELIUM_000100422_612GNAAXX:7:108:5640:3823#0/1 {\"ali_dir\":\"left\",\"ali_length\":62,\"mode\":\"alignment\",\"pairing_mismatches\":{\"(T:26)->(G:13)\":62,\"(T:34)->(G:18)\":48},\"score\":484,\"score_norm\":0.968,\"seq_a_single\":46,\"seq_ab_match\":60,\"seq_b_single\":46}\nccgcctcctttagataccccactatgcttagccctaaacacaagtaattaatataacaaaattgttcgccagagtactaccggcaatagcttaaaactcaaaggacttggcggtgctttatacccttctagaggagcctgttctaaggaggcgg\n+\nCCCCCCCBCCCCCCCCCCCCCCCCCCCCCCBCCCCCBCCCCCCC<CcCccbe[`F`accXV<TA\\RYU\\\\ee_e[XZ[XEEEEEEEEEE?EEEEEEEEEEDEEEEEEECCCCCCCCCCCCCCCCCCCCCCCACCCCCACCCCCCCCCCCCCCCC\n\n\n2.2.3 Assign each sequence record to the corresponding sample/marker combination\nEach sequence record is assigned to its corresponding sample and marker using the data provided in a text file (here wolf_diet_ngsfilter.txt). This text file contains one line per sample, with the name of the experiment (several experiments can be included in the same file), the name of the tags (for example: aattaac if the same tag has been used on each extremity of the PCR products, or aattaac:gaagtag if the tags were different), the sequence of the forward primer, the sequence of the reverse primer, the letter T or F for sample identification using the forward primer and tag only or using both primers and both tags, respectively (see obimultiplex for details).\n\nobimultiplex -t wolf_data/wolf_diet_ngsfilter.txt \\\n             -u results/unidentified.fastq \\\n             results/wolf.ali.fastq \\\n             > results/wolf.ali.assigned.fastq\n\nThis command creates two files:\n\nunidentified.fastq containing all the sequence records that were not assigned to a sample/marker combination\nwolf.ali.assigned.fastq containing all the sequence records that were properly assigned to a sample/marker combination\n\nNote that each sequence record of the wolf.ali.assigned.fastq file contains only the barcode sequence as the sequences of primers and tags are removed by the obimultiplex program. Information concerning the experiment, sample, primers and tags is added as attributes in the sequence header.\nFor instance, the first sequence record of wolf.ali.assigned.fastq is:\n@HELIUM_000
  },
  {
    "objectID": "commands.html#specifying-the-input-files-to-obitools-commands",
    "href": "commands.html#specifying-the-input-files-to-obitools-commands",
    "title": "3  The OBITools V4 commands",
    "section": "3.1 Specifying the input files to OBITools commands",
    "text": "3.1 Specifying the input files to OBITools commands"
  },
  {
    "objectID": "commands.html#options-common-to-most-of-the-obitools-commands",
    "href": "commands.html#options-common-to-most-of-the-obitools-commands",
    "title": "3  The OBITools V4 commands",
    "section": "3.2 Options common to most of the OBITools commands",
    "text": "3.2 Options common to most of the OBITools commands\n\n3.2.1 Specifying input format\nFive sequence formats are accepted for input files. Fasta and Fastq are the main ones, EMBL and Genbank allow the use of flat files produced by these two international databases. The last one, ecoPCR, is maintained for compatibility with previous OBITools and allows to read ecoPCR outputs as sequence files.\n\n--ecopcr : Read data following the ecoPCR output format.\n--embl Read data following the EMBL flatfile format.\n--genbank Read data following the Genbank flatfile format.\n\nSeveral encoding schemes have been proposed for quality scores in Fastq format. Currently, OBITools considers Sanger encoding as the standard. For reasons of compatibility with older datasets produced with Solexa sequencers, it is possible, by using the following option, to force the use of the corresponding quality encoding scheme when reading these older files.\n\n--solexa Decodes quality string according to the Solexa specification. (default: false)\n\n\n\n3.2.2 Specifying output format\nOnly two output sequence formats are supported by OBITools, Fasta and Fastq. Fastq is used when output sequences are associated with quality information. Otherwise, Fasta is the default format. However, it is possible to force the output format by using one of the following two options. Forcing the use of Fasta results in the loss of quality information. Conversely, when the Fastq format is forced with sequences that have no quality data, dummy qualities set to 40 for each nucleotide are added.\n\n--fasta-output Read data following the ecoPCR output format.\n--fastq-output Read data following the EMBL flatfile format.\n\nOBITools allows multiple input files to be specified for a single command.\n\n--no-order When several input files are provided, indicates that there is no order among them. (default: false)\n\n\n\n3.2.3 Format of the annotations in Fasta and Fastq files\nOBITools extend the Fasta and Fastq formats by introducing a format for the title lines of these formats allowing to annotate every sequence. While the previous version of OBITools used an ad-hoc format for these annotation, this new version introduce the usage of the standard JSON format to store them.\nOn input, OBITools automatically recognize the format of the annotations, but two options allows to force the parsing following one of them. You should normally not need to use these options.\n\n--input-OBI-header FASTA/FASTQ title line annotations follow OBI format. (default: false)\n--input-json-header FASTA/FASTQ title line annotations follow json format. (default: false)\n\nOn output, by default annotation are formatted using the new JSON format. For compatibility with previous version of OBITools and with external scripts and software, it is possible to force the usage of the previous OBITools format.\n\n--output-OBI-header|-O output FASTA/FASTQ title line annotations follow OBI format. (default: false)\n--output-json-header output FASTA/FASTQ title line annotations follow json format. (default: false)\n\n\n3.2.3.1 System related options\n\n--debug (default: false)\n--help\\|-h\\|-? (default: false)\n--max-cpu <int> Number of parallele threads computing the result (default: 10)\n--workers\\|-w <int> Number of parallele threads computing the result (default: 9)"
  },
  {
    "objectID": "commands.html#obitools-expression-language",
    "href": "commands.html#obitools-expression-language",
    "title": "3  The OBITools V4 commands",
    "section": "3.3 OBITools expression language",
    "text": "3.3 OBITools expression language\nSeveral OBITools (e.g. obigrep, obiannotate) allow the user to specify some simple expressions to compute values or define predicates. This expressions are parsed and evaluated using the gval go package, which allows for evaluating go-Like expression.\n\n3.3.1 Variables usable in the expression\n\n3.3.1.1 sequence\nsequence is the sequence object on which the expression is evaluated\n\n\n3.3.1.2 annotation\n\n\n\n3.3.2 Function defined in the language\n\n3.3.2.1 len\n\n\n3.3.2.2 ismap\n\n\n3.3.2.3 hasattribute\n\n\n3.3.2.4 min\n\n\n3.3.2.5 max\n\n\n\n3.3.3 Accessing to the sequence annotations"
  },
  {
    "objectID": "commands.html#metabarcode-design-and-quality-assessment",
    "href": "commands.html#metabarcode-design-and-quality-assessment",
    "title": "3  The OBITools V4 commands",
    "section": "3.4 Metabarcode design and quality assessment",
    "text": "3.4 Metabarcode design and quality assessment\n\n3.4.0.1 obipcr\n\nReplace the ecoPCR original OBITools"
  },
  {
    "objectID": "commands.html#file-format-conversions",
    "href": "commands.html#file-format-conversions",
    "title": "3  The OBITools V4 commands",
    "section": "3.5 File format conversions",
    "text": "3.5 File format conversions\n\n3.5.0.1 obiconvert"
  },
  {
    "objectID": "commands.html#sequence-annotations",
    "href": "commands.html#sequence-annotations",
    "title": "3  The OBITools V4 commands",
    "section": "3.6 Sequence annotations",
    "text": "3.6 Sequence annotations\n\n3.6.0.1 obitag"
  },
  {
    "objectID": "commands.html#computations-on-sequences",
    "href": "commands.html#computations-on-sequences",
    "title": "3  The OBITools V4 commands",
    "section": "3.7 Computations on sequences",
    "text": "3.7 Computations on sequences\n\n3.7.1 obipairing\n\nReplace the illuminapairedends original OBITools\n\n\n3.7.1.1 Alignment procedure\nobipairing is introducing a new alignment algorithm compared to the illuminapairedend command of the OBITools V2. Nethertheless this new algorithm has been design to produce the same results than the previous, except in very few cases.\nThe new algorithm is a two-step procedure. First, a FASTN-type algorithm (Lipman and Pearson 1985) identifies the best offset between the two matched readings. This identifies the region of overlap.\nIn the second step, the matching regions of the two reads are extracted along with a flanking sequence of \\(\\Delta\\) base pairs. The two subsequences are then aligned using a “one side free end-gap” dynamic programming algorithm. This latter step is only called if at least one mismatch is detected by the FASTP step.\nUnless the similarity between the two reads at their overlap region is very low, the addition of the flanking regions in the second step of the alignment ensures the same alignment as if the dynamic programming alignment was performed on the full reads.\n\n\n3.7.1.2 The scoring system\nIn the dynamic programming step, the match and mismatch scores take into account the quality scores of the two aligned nucleotides. By taking these into account, the probability of a true match can be calculated for each aligned base pair.\nIf we consider a nucleotide read with a quality score \\(Q\\), the probability of misreading this base (\\(P_E\\)) is : \\[\nP_E = 10^{-\\frac{Q}{10}}\n\\]\nThus, when a given nucleotide \\(X\\) is observed with the quality score \\(Q\\). The probability that \\(X\\) is really an \\(X\\) is :\n\\[\nP(X=X) = 1 - P_E\n\\]\nOtherwise, \\(X\\) is actually one of the three other possible nucleotides (\\(X_{E1}\\), \\(X_{E2}\\) or \\(X_{E3}\\)). If we suppose that the three reading error have the same probability :\n\\[\nP(X=X_{E1}) = P(X=X_{E3}) = P(X=X_{E3}) = \\frac{P_E}{3}\n\\]\nAt each position in an alignment where the two nucleotides \\(X_1\\) and \\(X_2\\) face each other (not a gapped position), the probability of a true match varies depending on whether \\(X_1=X_2\\), an observed match, or \\(X_1 \\neq X_2\\), an observed mismatch.\nProbability of a true match when \\(X_1=X_2\\)\nThat probability can be divided in two parts. First \\(X_1\\) and \\(X_2\\) have been correctly read. The corresponding probability is :\n\\[\n\\begin{aligned}\nP_{TM} &= (1- PE_1)(1-PE_2)\\\\\n       &=(1 - 10^{-\\frac{Q_1}{10} } )(1 - 10^{-\\frac{Q_2}{10}} )\n\\end{aligned}\n\\]\nSecondly, a match can occure if the true nucleotides read as \\(X_1\\) and \\(X_2\\) are not \\(X_1\\) and \\(X_2\\) but identical.\n\\[\n\\begin{aligned}\nP(X_1==X_{E1}) \\cap P(X_2==X_{E1}) &= \\frac{P_{E1} P_{E2}}{9} \\\\\nP(X_1==X_{Ex}) \\cap P(X_2==X_{Ex}) & = \\frac{P_{E1} P_{E2}}{3}\n\\end{aligned}\n\\]\nThe probability of a true match between \\(X_1\\) and \\(X_2\\) when \\(X_1 = X_2\\) an observed match :\n\\[\n\\begin{aligned}\nP(MATCH | X_1 = X_2) = (1- PE_1)(1-PE_2) + \\frac{P_{E1} P_{E2}}{3}\n\\end{aligned}\n\\]\nProbability of a true match when \\(X_1 \\neq X_2\\)\nThat probability can be divided in three parts.\n\n\\(X_1\\) has been correctly read and \\(X_2\\) is a sequencing error and is actually equal to \\(X_1\\). \\[\nP_a =  (1-P_{E1})\\frac{P_{E2}}{3}\n\\]\n\\(X_2\\) has been correctly read and \\(X_1\\) is a sequencing error and is actually equal to \\(X_2\\). \\[\nP_b =  (1-P_{E2})\\frac{P_{E1}}{3}\n\\]\n\\(X_1\\) and \\(X_2\\) corresponds to sequencing error but are actually the same base \\(X_{Ex}\\) \\[\nP_c = 2\\frac{P_{E1} P_{E2}}{9}\n\\]\n\nConsequently : \\[\n\\begin{aligned}\nP(MATCH | X_1 \\neq X_2) =  (1-P_{E1})\\frac{P_{E2}}{3} +  (1-P_{E2})\\frac{P_{E1}}{3} + 2\\frac{P_{E1} P_{E2}}{9}\n\\end{aligned}\n\\]\nProbability of a match under the random model\n\n\n\n\n\nEvolution of the match and mismatch scores when the quality of base is 20 while the second range from 10 to 40.\n\n\n\n\n\n\n3.7.1.3 obimultiplex\n\nReplace 
  },
  {
    "objectID": "commands.html#sequence-sampling-and-filtering",
    "href": "commands.html#sequence-sampling-and-filtering",
    "title": "3  The OBITools V4 commands",
    "section": "3.8 Sequence sampling and filtering",
    "text": "3.8 Sequence sampling and filtering\n\n3.8.0.1 obigrep\n\n\n3.8.1 Utilities\n\n3.8.1.1 obicount\n\n\n3.8.1.2 obidistribute\n\n\n3.8.1.3 obifind\n\nReplace the ecofind original OBITools.\n\n\n\n\n\nLipman, D J, and W R Pearson. 1985. “Rapid and sensitive protein similarity searches.” Science 227 (4693): 1435–41. http://www.ncbi.nlm.nih.gov/pubmed/2983426."
  },
  {
    "objectID": "library.html#biosequence",
    "href": "library.html#biosequence",
    "title": "4  The GO OBITools library",
    "section": "4.1 BioSequence",
    "text": "4.1 BioSequence\nThe BioSequence class is used to represent biological sequences. It allows for storing : - the sequence itself as a []byte - the sequencing quality score as a []byte if needed - an identifier as a string - a definition as a string - a set of (key, value) pairs in a map[sting]interface{}\nBioSequence is defined in the obiseq module and is included using the code\nimport (\n    \"git.metabarcoding.org/lecasofts/go/obitools/pkg/obiseq\"\n)\n\n4.1.1 Creating new instances\nTo create new instance, use\n\nMakeBioSequence(id string, sequence []byte, definition string) obiseq.BioSequence\nNewBioSequence(id string, sequence []byte, definition string) *obiseq.BioSequence\n\nBoth create a BioSequence instance, but when the first one returns the instance, the second returns a pointer on the new instance. Two other functions MakeEmptyBioSequence, and NewEmptyBioSequence do the same job but provide an uninitialized objects.\n\nid parameters corresponds to the unique identifier of the sequence. It mist be a string constituted of a single word (not containing any space).\nsequence is the DNA sequence itself, provided as a byte array ([]byte).\ndefinition is a string, potentially empty, but usualy containing a sentence explaining what is that sequence.\n\nimport (\n    \"git.metabarcoding.org/lecasofts/go/obitools/pkg/obiseq\"\n)\n\nfunc main() {\n    myseq := obiseq.NewBiosequence(\n        \"seq_GH0001\",\n        bytes.FromString(\"ACGTGTCAGTCG\"),\n        \"A short test sequence\",\n        )\n}\nWhen formated as fasta the parameters correspond to the following schema\n>id definition containing potentially several words\nsequence\n\n\n4.1.2 End of life of a BioSequence instance\nWhen an instance of BioSequence is no longer in use, it is normally taken over by the GO garbage collector. If you know that an instance will never be used again, you can, if you wish, call the Recycle method on it to store the allocated memory elements in a pool to limit the allocation effort when many sequences are being handled. Once the recycle method has been called on an instance, you must ensure that no other method is called on it.\n\n\n4.1.3 Accessing to the elements of a sequence\nThe different elements of an obiseq.BioSequence must be accessed using a set of methods. For the three main elements provided during the creation of a new instance methodes are :\n\nId() string\nSequence() []byte\nDefinition() string\n\nIt exists pending method to change the value of these elements\n\nSetId(id string)\nSetSequence(sequence []byte)\nSetDefinition(definition string)\n\nimport (\n    \"fmt\"\n    \"git.metabarcoding.org/lecasofts/go/obitools/pkg/obiseq\"\n)\n\nfunc main() {\n    myseq := obiseq.NewBiosequence(\n        \"seq_GH0001\",\n        bytes.FromString(\"ACGTGTCAGTCG\"),\n        \"A short test sequence\",\n        )\n\n    fmt.Println(myseq.Id())\n    myseq.SetId(\"SPE01_0001\")\n    fmt.Println(myseq.Id())\n}\n\n4.1.3.1 Different ways for accessing an editing the sequence\nIf Sequence()and SetSequence(sequence []byte) methods are the basic ones, several other methods exist.\n\nString() string return the sequence directly converted to a string instance.\nThe Write method family allows for extending an existing sequence following the buffer protocol.\n\nWrite(data []byte) (int, error) allows for appending a byte array on 3’ end of the sequence.\nWriteString(data string) (int, error) allows for appending a string.\nWriteByte(data byte) error allows for appending a single byte.\n\n\nThe Clear method empties the sequence buffer.\nimport (\n    \"fmt\"\n    \"git.metabarcoding.org/lecasofts/go/obitools/pkg/obiseq\"\n)\n\nfunc main() {\n    myseq := obiseq.NewEmptyBiosequence()\n\n    myseq.WriteString(\"accc\")\n    myseq.WriteByte(byte('c'))\n    fmt.Println(myseq.String())\n}\n\n\n4.1.3.2 Sequence quality scores\nSequence quality scores cannot be initialized at the time of instance creation. You must use dedicated methods to add quality scores to a sequence.\nTo be coherent the length of both the DNA sequence and que qu
  },
  {
    "objectID": "library.html#the-sequence-iterator",
    "href": "library.html#the-sequence-iterator",
    "title": "4  The GO OBITools library",
    "section": "4.2 The sequence iterator",
    "text": "4.2 The sequence iterator\nThe pakage obiter provides an iterator mecanism for manipulating sequences. The main class provided by this package is obiiter.IBioSequence. An IBioSequence iterator provides batch of sequences.\n\n4.2.1 Basic usage of a sequence iterator\nMany functions, among them functions reading sequences from a text file, return a IBioSequence iterator. The iterator class provides two main methods:\n\nNext() bool\nGet() obiiter.BioSequenceBatch\n\nThe Next method moves the iterator to the next value, while the Get method returns the currently pointed value. Using them, it is possible to loop over the data as in the following code chunk.\nimport (\n    \"git.metabarcoding.org/lecasofts/go/obitools/pkg/obiformats\"\n)\n\nfunc main() {\n    mydata := obiformats.ReadFastSeqFromFile(\"myfile.fasta\")\n       \n    for mydata.Next() {\n        data := mydata.Get()\n        //\n        // Whatever you want to do with the data chunk\n        //\n    }\n}\nAn obiseq.BioSequenceBatch instance is a set of sequences stored in an obiseq.BioSequenceSlice and a sequence number. The number of sequences in a batch is not defined. A batch can even contain zero sequences, if for example all sequences initially included in the batch have been filtered out at some stage of their processing.\n\n\n4.2.2 The Pipable functions\nA function consuming a obiiter.IBioSequence and returning a obiiter.IBioSequence is of class obiiter.Pipable.\n\n\n4.2.3 The Teeable functions\nA function consuming a obiiter.IBioSequence and returning two obiiter.IBioSequence instance is of class obiiter.Teeable."
  },
  {
    "objectID": "annexes.html",
    "href": "annexes.html",
    "title": "5  Annexes",
    "section": "",
    "text": "5.0.1 Sequence attributes\n\n5.0.1.1 Reserved sequence attributes\n\n5.0.1.1.1 ali_dir\n\n5.0.1.1.1.1 Type : string\nThe attribute can contain 2 string values \"left\" or \"right\".\n\n\n5.0.1.1.1.2 Set by the obipairing tool\nThe alignment generated by obipairing is a 3’-end gap free algorithm. Two cases can occur when aligning the forward and reverse reads. If the barcode is long enough, both the reads overlap only on their 3’ ends. In such case, the alignment direction ali_dir is set to left. If the barcode is shorter than the read length, the paired reads overlap by their 5’ ends, and the complete barcode is sequenced by both the reads. In that later case, ali_dir is set to right.\n\n\n\n5.0.1.1.2 ali_length\n\n5.0.1.1.2.1 Set by the obipairing tool\nLength of the aligned parts when merging forward and reverse reads\n\n\n\n5.0.1.1.3 count : the number of sequence occurrences\n\n5.0.1.1.3.1 Set by the obiuniq tool\nThe count attribute indicates how-many strictly identical sequences have been merged in a single record. It contains an integer value. If it is absent this means that the sequence record represents a single occurrence of the sequence.\n\n\n5.0.1.1.3.2 Getter : method Count()\nThe Count() method allows to access to the count attribute as an integer value. If the count attribute is not defined for the given sequence, the value 1 is returned\n\n\n\n5.0.1.1.4 merged_*\n\n5.0.1.1.4.1 Type : map[string]int\n\n\n5.0.1.1.4.2 Set by the obiuniq tool\nThe -m option of the obiuniq tools allows for keeping track of the distribution of the values stored in given attribute of interest. Often this option is used to summarise distribution of a sequence variant accross samples when obiuniq is run after running obimultiplex. The actual name of the attribute depends on the name of the monitored attribute. If -m option is used with the attribute sample, then this attribute names merged_sample.\n\n\n\n5.0.1.1.5 mode\n\n5.0.1.1.5.1 Set by the obipairing tool\nobitag_ref_index\n\n\n5.0.1.1.5.2 Set by the obirefidx tool.\nIt resumes to which taxonomic annotation a match to that sequence must lead according to the number of differences existing between the query sequence and the reference sequence having that tag.\n\n\n5.0.1.1.5.3 Getter : method Count()\n\n\n\n5.0.1.1.6 pairing_mismatches\n\n5.0.1.1.6.1 Set by the obipairing tool\n\n\n\n5.0.1.1.7 score\n\n5.0.1.1.7.1 Set by the obipairing tool\n\n\n\n5.0.1.1.8 score_norm\n\n5.0.1.1.8.1 Set by the obipairing tool"
  },
  {
    "objectID": "references.html",
    "href": "references.html",
    "title": "References",
    "section": "",
    "text": "Boyer, Frédéric, Céline Mercier, Aurélie Bonin, Yvan Le Bras, Pierre\nTaberlet, and Eric Coissac. 2016. “obitools:\na unix-inspired software package for DNA metabarcoding.”\nMolecular Ecology Resources 16 (1): 176–82. https://doi.org/10.1111/1755-0998.12428.\n\n\nCock, Peter JA, Christopher J Fields, Naohisa Goto, Michael L Heuer, and\nPeter M Rice. 2010. “The Sanger FASTQ File Format for Sequences\nwith Quality Scores, and the Solexa/Illumina FASTQ Variants.”\nNucleic Acids Research 38 (6): 1767–71.\n\n\nLipman, D J, and W R Pearson. 1985. “Rapid\nand sensitive protein similarity searches.”\nScience 227 (4693): 1435–41. http://www.ncbi.nlm.nih.gov/pubmed/2983426.\n\n\nRiaz, Tiayyba, Wasim Shehzad, Alain Viari, François Pompanon, Pierre\nTaberlet, and Eric Coissac. 2011. “ecoPrimers: inference of new DNA barcode markers from\nwhole genome sequence analysis.” Nucleic Acids\nResearch 39 (21): e145. https://doi.org/10.1093/nar/gkr732.\n\n\nSeguritan, V, and F Rohwer. 2001. “FastGroup:\na program to dereplicate libraries of 16S rDNA sequences.”\nBMC Bioinformatics 2 (October): 9. https://doi.org/10.1186/1471-2105-2-9.\n\n\nShehzad, Wasim, Tiayyba Riaz, Muhammad A Nawaz, Christian Miquel, Carole\nPoillot, Safdar A Shah, Francois Pompanon, Eric Coissac, and Pierre\nTaberlet. 2012. “Carnivore diet analysis\nbased on next-generation sequencing: Application to the leopard cat\n(Prionailurus bengalensis) in Pakistan.” Molecular\nEcology 21 (8): 1951–65. https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1365-294X.2011.05424.x."
  }
]