 |
|
Wise2 - Documentation (version 2.1.20 stable)
Contents
Overview
Wise2's particular forte is the comparison of DNA sequence at the level of its protein translation. This comparison allows the simultaneous prediction of say gene structure with homology based alignment. There is currently no other package that I know of that contains this type of algorithm with a full blown gene prediction model and a hidden Markov model of a protein domain. Wise2 also contains other algorithms, such as the venerable Smith-Waterman algorithm, or more modern ones such as Stephen Altschul's generalised gap penalties, or even experimental ones developed in house, such as dba (see section 7.1). The development of these algorithms is due to the ease of developing such algorithms in the environment used by Wise2. Wise2 has also been written with an eye for reuse and maintainability. Although it is a pure C package you can access its functionality directly in Perl. Parts of the package (or the entire package) can be used by other C or C++ programs without name space clashes as all externally linked variables have the unique identifier Wise2 prep ended. Java and CORBA ports are being considered - see 8 the API section Finally Wise2, although implemented in C makes heavy use of the Dynamite code generating language. Dynamite was written for this project, by Ewan Birney. There is a separate documentation for Dynamite found at http://www.ebi.ac.uk/Dynamite. The Wise2 package was principally written by Ewan Birney, who wrote the main genewise and estwise programs. The protein comparison database search program was written by Richard Copley using the underlying Wise2 libraries. Wise2 also uses code from Sean Eddy for reading HMMs and for Extreme value distribution fitting. However the authorship of Wise2 should be more fairly distributed between the main authors and the wonderful alpha testers on wise-alpha. Special mention goes to Gos Micklem and Niclas Jareborg and for their work at testing and their patience in my coding over the last couple of years. Other notables are (in no apparent order) - Enoch Huang, Erik Sonnhammer, Doug Rusch, Steve Jones, Ian Korf, Iftach Nachman, George Hartzell and Lars Arvestead. I believe that program writing is a 50-50 partnership between the coders and the testers or developers, and these people have actively helped me make a much better package. The URL for Wise2 development is http://www.ebi.ac.uk/Wise2/programming.html and there is a mailing list to keep people up to date. Please join us!
Introduction for the impatient
Wise2 has four main executable programs using sequence inputs which are designed to provide access to the main algorithms sensibly. The algorithms you are interested in is genewise - compare protein information to genomic DNA and estwise - compare protein information to EST/cDNA DNA. These are the programs which you might use for this.
If you see error messages like Warning Error
Could not open human.gf as a genefrequency file
Warning Error
Could not read a GeneFrequency file in human.gf
...
This means that the environment variable WISECONFIGDIR has not been
set up correctly. You need to find where the distribution was downloaded
to (a directory called something like wise2.1.16b) and inside that
directory should be the configuration directory wisecfg. You need to
setenv WISECONFIGDIR to that directory.
In each of the programs the protein can either be a protein sequence or a protein profile HMM, as made by the HMMER package (both version 1 and version 2 HMMs can be read). Any of the databases can have one entry (in which case more efficient routines are used), and databases of profile HMMs, such as those provided by Pfam, can be used. The simple running of a protein sequence (drosophila) vs a human genomic sequence, using genewise is given below. The output comes on stdout, which in normal unix notation can be redirected to a file.
adnah:[/birney/search]<98>: genewise road.pep hngen.fa
genewise (unreleased release)
This program is freely distributed under a GPL. See source directory
Copyright (c) GRL limited: portions of the code are from separate copyright
Query protein: roa1_drome
Comp Matrix: blosum62.bla
Gap open: 12
Gap extension: 2
Start/End local
Target Sequence HSHNRNPA
Strand: forward
Gene Paras: human.gf
Codon Table: codon.table
Subs error: 1e-05
Indel error: 1e-05
Model splice? model
Model codon bias? flat
Model intron bias? tied
Null model syn
Algorithm 623
Find start end points: [25,1387][346,3962] Score 87719
Recovering alignment: Alignment recoveredExplicit read offone 94%
genewise output
Score 253.10 bits over entire alignment
Scores as bits over a synchronous coding model
Warning: The bits scores is not probablistically correct for single seqs
See WWW help for more info
roa1_drome 88 AQKSRPHKIDGRVVEPKRAVPRQ DID
A +RPHK+DGRVVEPKRAV R+ D
AMNARPHKVDGRVVEPKRAVSRE DSQ
HSHNRNPA 1867 gaagaccagggagggcaaggtagGTGAGTG Intron 2 TAGgtc
ctacgcaataggttacagctcga<0-----[1936 : 2083]-0>aca
tgtagacggtaatgaagatccaa tta
roa1_drome 114 SPNAGATVKKLFVGALKDDHDEQSIRDYFQHFGNIVDINIVIDKETGKK
P A TVKK+FVG +K+D +E +RDYF+ +G I I I+ D+ +GKK
RPGAHLTVKKIFVGGIKEDTEEHHLRDYFEQYGKIEVIEIMTDRGSGKK
HSHNRNPA 2093 acggctagaaatgggaaggaggcccagttgctgaaggagaaagcgagaa
gcgcatctaatttggtaaacaaaatgaataaagatattattcaggggaa
aatccatgagatttctaactaatcaatttagtaatagtacgtcactcga
roa1_drome 163 RGFAFVEFDDYDPVDKVV QKQHQ
RGFAFV FDD+D VDK+V QK H
RGFAFVTFDDHDSVDKIV L:I[att] QKYHT
HSHNRNPA 2240 agtgtgatggcgtggaagAGTAAGTA Intron 3 TAGTTcatca
ggtcttctaaaactaatt <1-----[2295 : 2387]-1> aaaac
gctctactcctccgtgtc gactt
roa1_drome 187 LNGKMVDVKKALPKQNDQQGGGGGR
+NG +V+KAL KQ R
VNGHNCEVRKALSKQEMASASSSQR G:G[ggt]
HSHNRNPA 2405 gagcatggaagctacgagagttacaGGTATGCT Intron 4
tagaagatgactcaaatcgcccgag <1-----[2481 : 2793]
gtccctataacgagaggtttaccaa
...truncated
The output is as follows
The pretty alignment shows the protein sequence on the first line, followed by a line indicating the similarity level of the match followed by 4 lines representing the DNA sequence. The DNA sequence in the exons descending in triplets, each triplet being a codon. The translation of each codon is shown above it. Between the two protein sequences a line indicating the similarity of the match is printed. In introns the DNA sequence is not shown but for the first 7 bases (making the 5' splice site) and the last 3 bases of the 3' splice site. The intervening sequence is indicated in the square brackets. Above each intron, for phase 1 and 2 introns (ones that split a codon) the implied protein to conceptual gene match is displayed, with the codon in square brackets. Generally the defaults of the options are reasonably sensible, and for the main part you should trust them until you become familiar with the package. The following commands show how to run the other programs in a variety of different modes Running modes for genewise (genomic to protein comparisons). NB, the order of the -options are not important, but the protein file must be before the dna file
The estwise (protein to est/cDNA comparisons) have precisely the same running modes. Listed for completeness below
There are a number of common options that can be used. Options can be issued anywhere on the command line.
It hasn't given me a complete gene prediction The genewise algorithm does not attempt to predict an entire gene, from Met to STOP. It tries to predict regions which are justified with the protein homology and no more. This does mean you can be confident of the predictions that genewise makes
How can I get rid of the annoying messages on stderr? Some people like them. use -quiet Well... I have always had the philosophy that if it took you over a month to sequence a gene, then 4 hours in a computer is not an issue. However, in particular for times when people are using genewise simply to confirm that the a gene prediction is correct with respect to a protein sequence (sometimes the notional translation!) it is taking too long. In many cases you will know the rough region to compare the sequence to - if so use the -u and -v options to truncate your DNA at the correct points (the output will remain in the coordinates of the full length sequence). For database searching there is the option of using SMP boxes efficiently with the pthreads port. There are also a number of heuristics that use the BLAST program to provide the speed. These heuristics are found in the perl/scripts directory, called halfwise and blastwise and notes on how to use them are a later section (5). The scripts have extensive installation instructions, and I completely expect people to edit them for their system. There is functionality for providing a heuristic bound to the space the algorithm explores in the alignment. This is done via the potential gene option in genewise. It is not well tested out.
I have a new cosmid. What do I do? One thing to do is to use the halfwise script available in the perl/scripts package. Another is to use the blastwise script.
Can I modify or use the Wise2 source code? Of course you can - it is Open Source code, licensed under the Gnu Public Licensed (GPL'd), like emacs or gcc. For more information on this License read the GNULICENSE file in the distribution. As well as using the source code, you can if you like contribute directly back into the Wise2 source code. Get in contact with me if you would like to do this.
Making a single gene prediction on the basis of a close homolog This is perhaps the easiest use of genewise. The basic formulation is %genewise protein.fasta dna.fastaTo get out computer parsable formats of the gene prediction try -genes or -gff or -ace. To get out the protein translation in one go use -trans Using non human/worm/fly genomic DNA At the moment, genewise only has gene frequency files for human and worm sequences. The production of these files are based around somewhat annoying and non portable script. In any case, making a data set requires allot of effort as it needs to be clean The consequence of all this is that the species that you are comparing against (eg, hamster) may not have a gene frequency (.gf) file. In which case you basically have two options
Use genewise with the -alg 333 or -alg 333L options. This has all the outputs of genewise but does not consider introns. The -gene option and -intron, -splice options are all pointless. The only options to worry about is the -subs and -indel for substitution and insertion and deletion errors respectively. Use the estwise/estwisedb programs
Getting out the protein translation You have three approaches for getting out protein translations
Pfam can be used with the genewisedb or the estwisedb program with the -pfam flag. Usually you want to also use the -dnas (single DNA sequence flag) as well. An example run would be genewisedb -pfam Pfam -dnas myseq.faIf you have set up the HMMER package to work with Pfam using the environment variable HMMERDB, Wise2 will also pick that up as well.
Wise2 assumes you have a rather small amount of memory (20 MBytes).
When it is making an alignment, if it cannot make the explicit matrix
in that size (being length of query If you have more memory than 20 Mbytes, then it is really sensible to up the number, using the -kbyte option. For a machine with say 64Mbytes physical memory I would suggest putting an upper limit of 50Mbytes with -kbyte. This does assume you are not using it for anything else. You can change the compile time default in basematrix.h if you can't be bothered to remember to change it every time See sections 2.4 and 2.5 for use of these programs in large scale throughput environments. Make sure you have compiled with optimisation. If you are using the make all from the top level you have. If you are using gcc, make sure you are using -O2 optimisation, and probably crank it all the way up. If you have a large SMP box, you can compile with pthread support. The searches work on SGI/Compaq alpha/Suns. There are some issues about some architecture ports, which I need to expand somewhere in the docs, but first off, just try compiling with pthreads (3.3) and using pthreads in the search. For real, order-of-magnitude speed ups, you are going to have to use a heuristic stage before the actual database search - in other words, using BLAST. I dislike this, but it is fact of life, and there are two scripts in perl/scripts, halfwise and blastwise (5), which help you do this. Both scripts use Steve Chervitz excellent perl BLAST parser, which is available in bioperl. (Make sure you have a 0.05 release or later of bioperl, as the BLAST parser in the 0.05 release is much better).
halfwise is a pretty sensible, self contained script. blastwise I expect people to modify heavily to get to work as wished on their systems. Please read it, and add in your own heuristics (eg, figuring out start/end points). I am very interested in better heuristics in this area.
segmentation fault = bottle of champagne You've found a bug? I am really keen to hear from you. I want to hear about the problems you've got. Each year I award my best tester with a prize. This year (1998/99) it will be a bottle of champagne. Send a mail to birney@ebi.ac.uk for your prize!
Using GeneWise in a large scale throughput manner If you are analysing genomic DNA in a large scale manner, you might wonder what is the best way to use genewise. Genewise is very CPU expensive compared to other programs. Part of this is because I have concentrated much more on correctness of the algorithm, not its speed (it is probably about 2 fold slower than it could be optimally), but mainly this is because the algorithm is complicated and DNA sequence is generally very large. I do not believe that optimising genewise in the code will solve people's CPU problems. For these reasons, I do not advise the serious use of genewisedb as a single executable for comparing DNA sequence to either Pfam or protein databases. For these cases I suggest using the halfwise and blastwise scripts. See the section on Halfwise and BLASTwise (5
Another option is to get in contact with Compugen or Paracel, both of whom may be able to sell you specialised hardware which can either approximate a genewise search sensibly (or somewhat sensibly) or, in case of Compugen's Bioxl/g, actually run a full genewise type algorithm.
Using EstWise in a large scale throughput manner Estwise in a large scale manner is a more troubling issue than genewise. Generally the DNA databases are as large, but the algorithm is smaller and often people are equally interested in sensitivity and alignment quality. Therefore it makes more sense to use estwise directly as the database search. Estwise is still pretty slow, so here is a check list of things to do
I am thinking about improvements to the estwise running time. I would very much like to collaborate with someone on estwise in terms of understanding its sensitivity and improving all aspects of the algorithm. Please get in contact with me. The hardware solutions from Compugen, Paracel and Time Logic are all very good in this area, and worth investigating if you have money to spend.
Installation
The release is distributed as a gzipped, tar file. To unzip and untar in a single command you can type
%zcat wise2.1.12b.tar.gz | tar -xvf - This will untar into a directory called 'wise2.1.12b' (of course, your version of Wise2 might be different). Once you have made the tar file, it should build completely cleanly as long as you have an ANSI C compiler. If in doubt, just assume that it is, but in particular sun users might want to use gcc (gnu cc) as the sun cc compiler installed by default is often non-ANSI. To change the cc compiler you only need to edit the line in the top level makefile called CC = cc to CC = gcc. To build the package type %cd wise2.1.12b %make all %make bin The executable files will now be in wise2.1.12b/bin I am interested in all compiler errors, and consider most of them to be bugs (which means if you report them you could be on the champagne list!) The Wise2 package needs to know where a number of files are (eg, the gene prediction statistics). These files are in the directory called wisecfg/. You will need to setenv WISECONFIGDIR to this directory (you can of course move the directory elsewhere, and set WISECONFIGDIR to it).
Building with thread support (for SMP machines) To build with pthread support you must switch on some extra compile time options before you type make all. These are found at the top of the makefile in the top directory, and it is pretty clear from the makefile what to do. See the section 6.5 for information on how to run pthreaded code. In some cases the pthreads do not schedule correctly, preventing multiple threads working on different processors at the same time. If you have this problem, trying compiling with -D HAS_PTHREAD_SETSCOPE on the CFLAGS line. The pthreaded code has been reported to be 97there have been reports of up to 100 multiple threads running fine. To build with Perl support you need to go make perlat the top level. This should build everything correctly. The only problem is if you have a Solaris or *BSD box. If so you need to compile with -fpic or -fPIC depending on your compiler. This needs to go into the top level CFLAGS line. In addition, in the out-of-the box perl distribution for solaris they built it with a different compiler to the one it comes with (idiots!), so the perl generated makefile has the wrong -fpic option. You need to edit that by hand. Concepts and conventions
You can miss this section which describes some of the theoretical background of the work. The algorithms are based around a 'Bayesian' formalism that has been established in Bioinformatics by such people as David Haussler, Gary Churchill, Anders Krogh, Richard Durbin, Sean Eddy and Graeme Mitchinson, as well as many others. In this formalism there is assumed to be a generative model of the process that you are observing, which has probabilities to generate a number of different observations. Deciding whether this model fits a previously unseen piece of data or not is the first decision to make. Given that the data fits, a second question is what actual processes were the most likely to produce the observed data. Both these questions fit naturally into a Bayesian framework where the result is a posterior probability having seen the data. For people coming from a bioinformatics/biology background where the last paragraph may seem very confusing, it is only because this a different (and well established) field with their own terminology to describe the algorithms. In fact the methods a very close to standard techniques presented in bioinformatics. The generative models that we use are the models that are implied by the standard bioinformatics tools. For example, the Smith-Waterman algorithm implies a process of evolution with certain probabilities for seeing say an Leucine to Valine substitution and certain probabilities for creating and extending a insertion (gap). As you can see you can almost replace the word 'probability' with 'score' to return to the standard method, and mathematically it is almost that easy: the score is related to the log of the probability. Perhaps a better known example is the relationship between the old profile technology, as developed by Gribskov and Gibson along with others, and its probabilistic partner, profile Hidden Markov Models (profile HMMs). In terms of the actual algorithm these two methods are very similar: it is simply that the profile HMM has a strong probabilistic model underlying it, allowing well established techniques to be used in its generation.
Introduction to Models in Wise2 Wise2 contains a number of algorithms, each of which are based around one of two biological models.
This models themselves are built up from two component models, one for how protein residues are matched, and one for the gene prediction process. For the model of protein residues I have taken the established models of profile HMMs. The model of splicing and translation we developed with an eye to biology. It has many of the features of the GenScan model [chris Burge]. The model of translation (for estwise) is simple. The main model to understand is the genewise model (called genewise 21:93 for reasons discussed below). It is this model which the other models are based on - for the estwise models, by removing the intron generating part of the models, and for the other genewise algorithms by making approximations to genewise21:93. A diagrammatic representation of genewise21:93 is shown in the file genewise21.ps The central part of the model is the Match-Insert-Delete trio common to both profile HMMs (such as HMMER models) and the smith waterman model. This trio of states is one model 'position' in the profile HMMs, where each model position contains a Match, Insert and Delete states. This means to interpret the figure of the model in the way the profile HMM models are usually displayed, you have to imagine a series of these states concatenated together. I imagine the model growing as stack of pages out from the figure, each new page being a new position in the profile HMM. The first addition to the model are the frameshifting transitions, shown in with x4 boxes above them. These occur whenever there is a transition which produces a codon: in effect all transitions that terminate at either match or insert states. There are four frameshifting transitions in each Notice that there are frameshifting transitions from Delete to Match, which is equivalent to saying that a frameshift occurs on the codon just after a run of deletions in the model. It is these sorts of frameshifts that are not well modeled by other algorithms. The second addition involves the intron emitting states found in the green boxes. Each intron is modeled by having 5 regions, two of which are fixed length. The five regions are
Notice that there is no branch site, because we could not produce a good enough statistical model for it. This model can be modeled using 3 states, with the fixed length regions being accommodated using transitions which emitted the appropriate length of sequence. Each of the intron models must be duplicated 3 times to account for the 3 different phases of introns (each phase being a different placement of the intron relative to the codon), so we need to duplicated these 3 states at least 3 times. In addition, if this intron lies in an insert state, i.e., the surrounding protein sequence in the exons are being produced by an insert state in the underlying protein profile HMM, so we have to maintain that information across the intron. This means that we need to duplicate the intron states 6 times in total: 3 times for the different phases and twice on top of that for the different protein states this intron could lie in. The model presented above seems biological sensible, but how on earth are we going to parameterise it? Are we honestly going to let a user try to juggle the forty odd parameters inherent to this model? Clearly not. The approach we have taken to this is to provide set statistics derived from a maximum likelihood approach from known genes - this requires virtually no training - and then give switches to the user to turn on and off a variety of different parts of the algorithm. The model is parameterised as probabilities, but actually calculated in log space. If you look in the code you would find that there is allot of switching between the two spaces: these are provided by the functions Probability2Score and Score2Probability (notice that the 'Score' here is very specific to the Wise2 package - you can't put any old score into Score2Probability to get a probability out as it depends on how that Score was converted into Log space). For the emissions of the actually underlying amino acids when we have a profile HMM, we are lucky - we can take the probabilities defined in the HMMer2 models. This is completely natural and means I don't have to worry about deriving probabilities for the profile HMMs In the case where we have a protein sequence, I somehow have to get to a profile HMM type representation. Thankfully the smith waterman algorithm in terms of architecture is very close to a profile HMM, and so the only problem is mapping the usual scores used in the smith waterman algorithm to probabilities. This is quite hard to do correctly, but I've hacked it by knowing that the blosum62 matrix is given in half bits, in other words using a 2*log2 mapping from probability space to the give scores in the matrix. By reversing this process one can get pretty good emission probability for the amino acids. I now assume that the gap penalties are as if they were written in half bits. A certain amount of normalisation is required to make sure things add to one, and eh voila - one profile HMM from a single sequence. One interesting issue about the protein model is how the start end points work. For proteins it is obvious that for distant homology, it needs to be local - i.e. can start or finish anywhere in the sequence. For protein HMMs it is less clear. If a HMM really represents a single domain then global start end points are correct. However, many times local start end points are useful. The HMMer2 models internally carry whether this HMM is has global or local (or indeed any type) of start end policy. However, the genewise algorithm is quite dependent on the models being global to effectively predict introns in domains, when the looping algorithm (multiple copies of the domain) is present. This is because nearly always in a local HMM, an intron can be better modeled as the end of the domain half way through and the start of a new domain half way through, further down the sequence, thus not predicting the intron. To get clean intron prediction, one needs to go to global mode. However, using global mode forces the start and end point of the model to be really correct, and in some cases (in particular some Pfam models) this makes very incorrect results on the edges of the domain. To combat this another type of start end policy is introduced - wing. This has a local start mode for the first 15 model positions and end mode for the last 15 model positions, but global in the central part of the model. In the programs one can set four types of start end policy
For the emissions of the gene model we had to do more work. What we did was to make a database of known genes, with annotated gene structure. These genes then provided a raw set of counts for particular parts of the gene structure. It is these raw counts which are stored in the .gf files. (we store the raw counts because one might want to do something clever for deriving the probabilities of certain things using these counts. Counts are the basis for the probability derivations, not frequencies). The only issue here is what to do with the splice sites. We were well aware that the information in the splice sites is considerably more than just the simple position matrix. We chose to use a single branching (biased) decision tree, in which each branch either carried along the main trunk of the tree or ended in a leaf, each leaf representing a consensus build from A,T,G,C or N for any character. This decision tree could be easily constructed by choosing the most common consensus (where N is allowed where a position is better represented by N than any specific residue), and then removing that consensus from the list of observed consensi, and then repeating the process. This also gave us the same basis (counts) for each consensus used in the splice sites. One additional twist came about in the splice site development. The splice sites overlap between their consensi and the coding sequence region. These overlaps need to be treated correctly: the problem is that probabilistically we have two processes wanting to account for the same DNA bases. This was solved by assuming conditional independence between the two processes. A more formal mathematical approach can be found in the documented called 'probappendix'. The probability of the model has to compared to an alternative model (in fact to all alternative models which are possible) to allow proper Bayesian inference. This causes considerable difficulty in these algorithms because from a algorithmical point of view we would probably like to use an alternative model which is a single state, like the random model in profile-HMMs, where we can simply 'log-odd' the scored model, whereas from a biological point of view we probably want to use a full gene predicting alternative model. In addition we need to account for the fact that the protein HMM or protein homolog probably does not extend over all the gene sequence, nor in fact does the gene have to be the only gene in the DNA sequence. This means that there are very good splice sites/poly-pyrimidine tracts outside of the 'matched' alignment can severely de-rail the alignment. Basically we are in trouble with the random model parts of this problem. The solutions is different in the genewise21:93 compared to the genewise 6:23 algorithms
However this still does not solve the problem about what to compare it to. There are two approaches to the comparison
The algorithms are then based around this central model, but have a variety of features removed from it progressively, either due to biological constraints (bacterial sequences have no introns, so there is no need to model them) or to speed up the the algorithm. Algorithms are named in two parts, descriptive-word state-number:transition-number. The descriptive word indicates the biological model. At the moment there are 2 such biological models in the package
The state-number:transition-number is the number of states in the model followed by the number of transitions. GeneWise 21:93 is the most complicated model, with 21 states and 93 transitions. The number of states is directly proportional to the memory usage of the program. The number of transitions is roughly proportional to the CPU time of the algorithm. For comparison the standard smith waterman algorithm is a 3:7 algorithm (3 states, 7 transitions). These numbers are per compared residue - so as genomic DNA is some 1,000 fold longer than protein sequences on average, there is an additional massive CPU load. Finally the algorithms can be looping or not. A Looping algorithm is one in which the protein information can be repeated in the DNA target sequence. This could either be due to multiple copies of the gene in the DNA sequence or multiple copies of a domain in a single gene. Looping algorithms are given a 'L' tag. By default, when you use profile-HMMs you use a looping model For the genewise family the following algorithms are available.
For the estwise family the following algorithms are available
The scoring system for the algorithms, as eluded to earlier is a Bayesian score. This score is related to the probability that model provided in the algorithm exists in the sequence (often called the posterior). Rather than expressing this probability directly I report a log-odds ratio of the likelihood of the model compared to a random model of DNA sequence. This ratio (often called bits score because the log is base 2) should be such that a score of 0 means that the two alternatives it has this homology and it is a random DNA sequence are equally likely. However there are two features of the scoring scheme that are not worked into the score that means that some extra calculations are required
These two features mean that the reported bits score needs to be above some threshold which combines the effect of the prior probabilities and the need to have confidence in the posterior probability. In this field people do not tend to work the threshold out rigorously using the above technique, as in fact, deficiencies in the model mean that you end up choosing some arbitary number for a cutoff. In my experience, the following things hold true: bit scores above 35 nearly always mean that there is something there, bit scores between 25-35 generally are true, and bit scores between 18-25 in some families are true but in other families definitely noise. I don't trust anything with a bit score less than 15 bits for these DNA based searches. For protein-HMM to protein there are a number of cases where very negative bit scores are still 'real' (this is best shown by a classical statistical method, usually given as e-values, which is available from the HMMer2 package), but this doesn't seem to occur in the DNA searches. I have been thinking about using a classical statistic method on top of the bit score, assuming the distribution is an extreme value distribution (EVD), but for DNA it becomes difficult to know what to do with the problem of different lengths of DNA. As these can be wildly different, it is hard to know precisely how to handle it. Currently a single HMM compared to a DNA database can produce e-values using Sean Eddy's EVD fitting code but, I am not completely confident that I am doing the correct thing. Please use it, but keep in mind that it is an experimental feature.
Halfwise and BLASTwise
The halfwise database is made from the Pfam FULL alignments, made non redundant to 75being quite a small database. To install halfwise you need to
To run halfwise go halfwise dna.seq > dna.seq.hlf halfwise by itself gives you help about it. To run blastwise you will need
Install bioperl and blast as before, install the Wise2 perl port. Edit the blastwise.pl script, making sure you change protein database and the GETZ line lower down to represent the way of getting sequences. To run blastwise go blastwise.pl dna.seq > dna.seq.blw The blastwise script is designed to be adjusted to fit your site. There are a number of us world wide concentrating on extending and improving blastwise. Please get in touch if you want to help. Principle Programs
%genewise protein-file dna-file A number of options are common to these programs from the point of view of how they run
You will probably want to read the 2.1 common modes of usage section as well Genewise compares a protein sequence or a protein profile HMM to a dna sequence
genewise - options: dna/protein
All output options can be used at the same time. They are separated by the value to -divide option
genewisedb is the database searching version of genewise. It takes a
database of proteins and compares it to a database of dna sequences
genewisedb - search modes
Many of these options are identical to the genewise options listed above
For each alignment made by genewisedb you can output it as a number of different options
Each alignment produces a notional gene prediction. At the end of the output, these gene predictions can be displayed together. This only works for -pfam or -prodb and -dnas options, i.e. a database of protein information vs a single dna sequence In the future it is hoped that additional options (such as merging consistent gene predictions) will operate before these outputs are made
Estwise runs very much like genewise with basically a subset of
options. For completeness they are all listed below
estwise - options: dna/protein
estwisedb is the database searching version of the
estwise program. Like estwise, it has the same sort of
running modes as genewisedb, but with more limited options.
estwisedb - options: running modes
The two database searching programs, genewisedb and estwisedb can be run with pthread support on SMP boxes. To do so you need to compile the source code with pthread support (it is very easy, see section 3.3). Then the programs need to be run with the additional option -pthread. On most machines the executable will pick up the number of available processors automatically and run that number of threads. If you want to override this use the -pthr_no option.
Other Programs
dba - standing for Dna Block Aligner, was developed by Niclas Jareborg, Richard Durbin and Ewan Birney for characterising shared regulatory regions of genomic DNA, either in upstream regions or introns of genes The idea was that in these regions there would a series of shared motifs, perhaps with one or two insertions or deletions but between motifs there would be any length of sequence. The subsequent model was a 3 state model which was log-odd'd ratio to a null model of their being no examples of a motif in the two sequences.
psw is a short and sweet program for calculating smith waterman alignments quickly. It was mainly written as C driver to test the underlying code which is more useful in things like the Perl port. More recently I added in the generalised gap penalty model of Stephen Altschul, that is known as the abc model in Wise2. The abc model is detailed in Proteins 1998 Jul 1, 32 pages 88-96.
pswdb - protein smith waterman database searching was written by Richard Copley using
the underlying Wise2 libraries
psw - options
API
If you end up parsing the programs in the Wise2 package allot, or repeatedly calling them to do something slightly at odds to the way they work, then you should probably be using the API. The API is quite easy to use once you have got used to the number of functions that you can call: all the hard parts of writing a C program, such as the underlying algorithms and memory management are conveniently hidden from you. A very good example of the use of the API is the blastwise script (5) and other scripts in the perl/scripts directory. The API (application programming interface) is a defined layer for you to write programs that use Wise2 functionality. The API has only a subset of the functions available internally to Wise2 (but still it is quite a daunting number). Currently there are two main ways to access the API - firstly using C function calls, and secondly using Perl function calls. In the latter case, the Wise2 code is 'compiled into' perl (in fact dynamically loaded - the unix equivalent of a dll file), meaning that although you call what looks like normal perl functions, it is actually executed by compiled C functions. The API interface is written in C, but with a very strong object model. This means that the C API can be easily mapped to an object based environment. In particular this is taken advantage of in the Perl case, where Perl objects are exported in the Perl space, allowing very idiomatic scripts to be written. The documentation for the API currently lies in the C header files and the Perl .pod files. This is something which I am actively working on at the moment. This is just a taster for you to see what one can do. For a more detailed examination, look at the API documentation.
#!/usr/local/bin/perl
#
# protestwise.pl <protein-seq-fasta> <dna-seq-fasta>\n
# produces on STDOUT a new protein sequence which is the
# DNA sequence 'fixed' by the comparison to the protein sequence.
# in particular frameshift errors get mapped to X
# written by James cuff (james@ebi.ac.uk)
# Hacked by Ewan (birney@ebi.ac.uk). Talk to ewan
# first about the script.
use Wise2;
my $pro_file = shift; # first argument from @ARGV
my $dna_file = shift; # second argument @ARGV
if( !defined $dna_file ) {
die "ProtESTwise.pl <protein-seq-fasta> <dna-seq>\n
Produces output of the DNA sequence\n'fixed' by the comparison on stdout";
}
# read in inputs. Read in first as generic 'Sequence' objects
# and then converted to specific 'Protein' or 'cdna' type
# objects
open(PRO,$pro_file) || die "Could not open $pro_file!";
$seq = &Wise2::Sequence::read_fasta_Sequence(\*PRO);
$pro = &Wise2::Protein::Protein_from_Sequence($seq);
if( $pro == 0 ) {
# can't interpolate function calls <sigh>
die sprintf("Could not make protein from sequence %s!",$seq->name());
}
open(DNA,$dna_file) || die "Could not open $pro_file!";
$seq = &Wise2::Sequence::read_fasta_Sequence(\*DNA);
$cdna = &Wise2::cDNA::cDNA_from_Sequence($seq);
if( $cdna == 0 ) {
# can't interpolate function calls <sigh>
die sprintf("Could not genomic from sequence %s!",$seq->name());
}
# Read in data structures needed for
# estwise type algorthim
#
# These will be automatically read from WISECONFIGDIR if necessary.
# this is the indel rate
$cp = &Wise2::flat_cDNAParser(0.001);
# codon table
$ct = &Wise2::CodonTable::read_CodonTable_file("codon.table");
#this means we are not using any codon bias
$cm = &Wise2::flat_CodonMapper($ct);
# this is the substitution error
$cm->sprinkle_errors_over_CodonMapper(0.001);
# random model needed if we are not using syn
$rmd = &Wise2::RandomModelDNA_std();
# means estwise3 algorithm. Not obvious!
$alg = 0;
# sets memory amount for main memory
&Wise2::change_max_BaseMatrix_kbytes(100000); # 10 Megabytes.
# these are for the protein part of the comparison
$comp = &Wise2::CompMat::read_Blast_file_CompMat("blosum62.bla");
$rm = &Wise2::default_RandomModel();
# do it!
$alb = &Wise2::AlnBlock_from_Protein_estwise_wrap
($pro,$cdna,$cp,$cm,$ct,$comp,-12,-2,0,$rmd,$alg,$rm,1);
$proseq = "";
#
# This is where we get clever!
#
# The for loops across the alignments. The protein sequence is in $alc->alu(0). The
# DNA sequence is in $alc->alu(1). We are interested in codons in the DNA sequence
# and turns those into amino acids. Sequence insertions or deletions become X's
#
for($alc=$alb->start();$alc->at_end() != 1;$alc = $alc->next()) {
if( $alc->alu(1)->text_label() =~ /^INSERT$/ ) {
next; # skip protein inserts relative to the DNA sequence
# NB different from SEQUENCE_INSERTION.
}
if( $alc->alu(1)->text_label() =~ /CODON/ ) {
# get out sequence from $start to $end
# $start and $end are in bio coordinates
$start = $alc->alu(1)->start+1;
$end = $alc->alu(1)->end+1;
$dnatemp = "";
for($x=$start;$x < $end;$x++){
$tmp = &Wise2::cDNA::cDNA_seqchar($cdna,$x);
$dnatemp=$dnatemp.$tmp;
}
$temp = $ct->aminoacid_from_seq($dnatemp);
# if codon has an N, then set the residue to unk X,
# we could be clever about this and work out what
# it is likely to be, but hell...
$temp =~ s/x/X/;
$proseq .= $temp;
} else {
# deletion or insertion of a base
$proseq .= 'X';
}
}
# make the new protein sequence and
# dump it to stdout
$namecdna = $cdna->baseseq()->name();
$new = &Wise2::new_Sequence_from_strings($namecdna,$proseq);
$new->write_fasta(STDOUT);
|
|
length of target