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."
  },
  {
    "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>>>>>>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[\\]^_`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\n1.2.4.1 Variations\n\n1.2.4.1.1 Quality\nA 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|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\n1.2.4.2 Encoding\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\nSequencing Control Software, Version 2.6, Catalog # SY-960-2601, Part # 15009921 Rev. A, November 2009] [http://watson.nci.nih.gov/solexa/Using_SCSv2.6_15009921_A.pdf\\\\](http://watson.nci.nih.gov/solexa/Using_SCSv2.6_15009921_A.pdf){.uri} (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@HWI-EAS209_0006_FC706VJ:5:58:5894:21141#ATCACG/1\nTTAATTGGTAAATAAATCTCCTAATAGCTTAGATNTTACCTTNNNNNNNNNNTAGTTTCTTGAGATTTGTTGGGGGAGACATTTTTGTGATTGCCTTGAT\n+HWI-EAS209_0006_FC706VJ:5:58:5894:21141#ATCACG/1\nefcfffffcfeefffcffffffddf`feed]`]_Ba_^__[YBBBBBBBBBBRTT\\]][]dddd`ddd^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 “unknown quality score”. The error rate of ‘B’ reads was roughly 3 phred scores lower the mean observed score of a given run.\n\nStarting in Illumina 1.8, the quality scores have basically returned to the use of the Sanger format (Phred+33)."
  },
  {
    "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": "commands.html#specifying-the-input-files-to-obitools-commands",
    "href": "commands.html#specifying-the-input-files-to-obitools-commands",
    "title": "2  The OBITools commands",
    "section": "2.1 Specifying the input files to OBITools commands",
    "text": "2.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": "2  The OBITools commands",
    "section": "2.2 Options common to most of the OBITools commands",
    "text": "2.2 Options common to most of the OBITools commands\n\n2.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\n2.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\n2.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\n2.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": "2  The OBITools commands",
    "section": "2.3 OBITools expression language",
    "text": "2.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\n2.3.1 Variables usable in the expression\n\n2.3.1.1 sequence\nsequence is the sequence object on which the expression is evaluated\n\n\n2.3.1.2 annotation\n\n\n\n2.3.2 Function defined in the language\n\n2.3.2.1 len\n\n\n2.3.2.2 ismap\n\n\n2.3.2.3 hasattribute\n\n\n2.3.2.4 min\n\n\n2.3.2.5 max\n\n\n\n2.3.3 Accessing to the sequence annotations"
  },
  {
    "objectID": "commands.html#metabarcode-design-and-quality-assessment",
    "href": "commands.html#metabarcode-design-and-quality-assessment",
    "title": "2  The OBITools commands",
    "section": "2.4 Metabarcode design and quality assessment",
    "text": "2.4 Metabarcode design and quality assessment\n\n2.4.0.1 obipcr\n\nReplace the ecoPCR original OBITools"
  },
  {
    "objectID": "commands.html#file-format-conversions",
    "href": "commands.html#file-format-conversions",
    "title": "2  The OBITools commands",
    "section": "2.5 File format conversions",
    "text": "2.5 File format conversions\n\n2.5.0.1 obiconvert"
  },
  {
    "objectID": "commands.html#sequence-annotations",
    "href": "commands.html#sequence-annotations",
    "title": "2  The OBITools commands",
    "section": "2.6 Sequence annotations",
    "text": "2.6 Sequence annotations\n\n2.6.0.1 obitag"
  },
  {
    "objectID": "commands.html#computations-on-sequences",
    "href": "commands.html#computations-on-sequences",
    "title": "2  The OBITools commands",
    "section": "2.7 Computations on sequences",
    "text": "2.7 Computations on sequences\n\n2.7.1 obipairing\n\nReplace the illuminapairedends original OBITools\n\n\n2.7.1.1 obimultiplex\n\nReplace the ngsfilter original OBITools\n\n\n\n2.7.1.2 obicomplement\n\n\n2.7.1.3 obiclean\n\n\n2.7.1.4 obiuniq"
  },
  {
    "objectID": "commands.html#sequence-sampling-and-filtering",
    "href": "commands.html#sequence-sampling-and-filtering",
    "title": "2  The OBITools commands",
    "section": "2.8 Sequence sampling and filtering",
    "text": "2.8 Sequence sampling and filtering\n\n2.8.0.1 obigrep\n\n\n2.8.1 Utilities\n\n2.8.1.1 obicount\n\n\n2.8.1.2 obidistribute\n\n\n2.8.1.3 obifind\n\nReplace the ecofind original OBITools."
  },
  {
    "objectID": "library.html#biosequence",
    "href": "library.html#biosequence",
    "title": "3  The GO OBITools library",
    "section": "3.1 BioSequence",
    "text": "3.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\n3.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\n3.1.2 End of life of a BioSequence instance\nWhen a BioSequence instance is no more used, it is normally taken in charge by the GO garbage collector. You can if you want call the Recycle method on the instance to store the allocated memory element in a pool to limit allocation effort when many sequences are manipulated.\n\n\n3.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\n3.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\n3.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 quality score sequence must be equal. But assessment of this constraint is realized. It is of the programmer responsability to check that invariant.\nWhile accessing to the quality scores relies on the method Quality() []byte, setting the quality need to call one of the following method. They run similarly to their sequence dedicated conterpart.\n\nSetQualities(qualities Quality)\nWriteQualities(data []byte) (int, error)\nWriteByteQualities(data byte) error\n\nIn a way analogous to the Clear method, ClearQualities() empties the sequence of quality scores."
  },
  {
    "objectID": "annexes.html",
    "href": "annexes.html",
    "title": "4  Annexes",
    "section": "",
    "text": "4.0.1 Sequence attributes\n\n4.0.1.1 Reserved sequence attributes\n\n4.0.1.1.1 ali_dir\n\n4.0.1.1.1.1 Type : string\nThe attribute can contain 2 string values \"left\" or \"right\".\n\n\n4.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\n4.0.1.1.2 ali_length\n\n4.0.1.1.2.1 Set by the obipairing tool\nLength of the aligned parts when merging forward and reverse reads\n\n\n\n4.0.1.1.3 count : the number of sequence occurrences\n\n4.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\n4.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\n4.0.1.1.4 merged_*\n\n4.0.1.1.4.1 Type : map[string]int\n\n\n4.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\n4.0.1.1.5 mode\n\n4.0.1.1.5.1 Set by the obipairing tool\nobitag_ref_index\n\n\n4.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\n4.0.1.1.5.3 Getter : method Count()\n\n\n\n4.0.1.1.6 pairing_mismatches\n\n4.0.1.1.6.1 Set by the obipairing tool\n\n\n\n4.0.1.1.7 score\n\n4.0.1.1.7.1 Set by the obipairing tool\n\n\n\n4.0.1.1.8 score_norm\n\n4.0.1.1.8.1 Set by the obipairing tool"
  },
  {
    "objectID": "references.html",
    "href": "references.html",
    "title": "References",
    "section": "",
    "text": "Cock, 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."
  }
]