D324 Nucleic Acids Research, 2009, Vol. 37, Database issue comparison of ConSurf-DB with these tools please see the supporting materials. The sequence homologues of each protein in ConSurf-DB are collected using PSI-BLAST (10) and then automatically ﬁltered in order to represent reliably and comprehensively the protein family. This process requires a delicate balance between two opposing eﬀects. A conservative search would yield only very close homo- logues and would make it virtually impossible to discrimi- nate between amino acid positions that are truly important and those that did not change because of insuf- ﬁcient evolutionary time. On the other hand, an overly permissive search may falsely detect non-homologues that do not share the same structure and/or function. We conducted preliminary investigations and came up with a scheme, presented below, which balances between these two extremes. The selected homologues are aligned using MUSCLE (11) and are available for use as part of the ConSurf-DB repository. The Rate4Site program is subsequently used to con- struct a phylogenetic tree and calculate conservation scores. Rate4Site builds a phylogenetic tree of the homo- logues using the neighbor joining algorithm (12). Using an empirical Bayesian approach it calculates the evolutionary rate of each amino acid position of the MSA, taking into account the stochastic nature of the evolutionary process. The amino acid evolution is traced using the JTT (13) substitution model. High evolutionary rate represents a variable position while low rate represents an evolutiona- rily conserved position. The conservation scores are normalized so that the average over all residues is zero, and the standard devia- tion is one. Low (negative) scores indicate the conserved positions while the high scores indicate the variable ones. The normalized scores are then binned into the 1–9 color codes presented in Figure 1, representing the conservation grades and projected on the 3D model of the query pro- tein, where 1 corresponds to maximal variability and 9 to maximal conservation. It is important to note that even though the same scale is used in all the protein families, the conservation scores are not absolute and hence, com- paring the conservation scores between diﬀerent protein families might be misleading. There are several ways to access the repository. For visual inspection of one or few proteins, a web interface, available at http://consurfdb.tau.ac.il/, supports 3D visua- lization (using FirstGlance in Jmol) and access to all sup- plementary data. The entire repository can be downloaded via ftp or rsync and used for large-scale automated studies. For advanced uses, involving re-building of variants of the repository, the build scripts can be down- loaded from the ConSurf-DB web site. We will be glad to assist in adopting them to diﬀerent environments. METHODOLOGY Building the ConSurf-DB repository consists of four stages: scanning the PDB (14), building MSA ﬁles, calcu- lating the conservation scores and formatting the results (supporting material, Figure 2). This design was chosen to allow reusability of the scripts by controlling the data at each step. For instance, an MSA ﬁle can be created by simply inputting a FASTA format sequence ﬁle to the MSA building script or if a Rate4Site output was obtained using a unique set of parameters, it can be used to create 3D visualization. A monthly update process will calculate the conservation proﬁles for new PDB entries. In the annual refresh, the entire database will be re-calculated based on MSAs created from the latest sequence databases. The ConSurf-DB build process is completely automated and starts by scanning the PDB. Each PDB entry can contain one or more chains that are handled separately. When a new PDB entry is found, the SEQRES section of each chain passes through three ﬁlters: ‘type’, ‘length’ and ‘modiﬁcations’. Nucleic acid chains are discarded by the ‘type’ ﬁlter, short amino acid chains of less than 30 resi- dues are discarded by the ‘length’ ﬁlter as they do not contain enough data for reliable phylogenetic tree recon- struction. Finally, the ‘modiﬁcation’ ﬁlter converts a list of non-standard residues into their closest standard amino acid form, and discards highly modiﬁed chains with over 15% non-standard residues. The modiﬁcations are noted and saved as part of the chain’s supplementary data. The next two steps rely solely on the sequence of amino acids in the chain. Identical sequences are grouped and processed once in order to avoid repetitive calculations. The second step in the process is the creation of the MSAs. Using PSI-BLAST we ﬁnd potential homologues in the UniProtKB/SwissProt (15) database using an e-value cutoﬀ of 10 3 and three iterations. The results are forwarded to a ﬁltering script that removes redundant sequences according to three criteria: (i) sequence identity—sequences with more than 95% identity to the query sequence are removed; (ii) sequence length— sequences shorter than 60% of the query sequence are removed; (iii) maximum overlap—since BLAST is a local alignment algorithm, fragment sequences that overlap by over 10% are also removed. Next, redundant sequences are removed using CD-HIT (16); a maximum of the 300 most signiﬁcant hits (i.e. sequences with the lowest e-values) are selected as homologues, and MUSCLE is used to align them. If a total of less than 50 homologues are found, the entire process is repeated using the Clean_UniProt data- base. Clean_UniProt is a modiﬁed version of the UniProt database (15) aimed to screen the more reliable sequences based on two criteria: (i) if the ‘Description’ (DE) ﬁeld contain ‘Disease’, ‘RIKEN’, ‘variant’, ‘mutation’, ‘mutant’ or ‘whole genome shotgun sequence’ the sequence is removed; (ii) if the database is ‘TrEMBL’ and the ‘Comments’ (CC) lines contain the word ‘CAUTION’ the sequence is removed. The Clean_UniProt includes non- reviewed entries and is about 10 times larger than UniProtKB/SwissProt. The number of chains supported by each sequence database is presented in Table 2 of the supporting materials. The third and most CPU-bound step is the execution of Rate4Site to produce the evolutionary scores for each amino acid position in the protein. A Condor (17) job system that is part of the European grid network was used to this end, which allowed us to complete this part