Fragger: a protein fragment picker for structural queries

Protein modeling and design activities often require querying the Protein Data Bank (PDB) with a structural fragment, possibly containing gaps. For some applications, it is preferable to work on a specific subset of the PDB or with unpublished structures. These requirements, along with specific user needs, motivated the creation of a new software to manage and query 3D protein fragments. Fragger is a protein fragment picker that allows protein fragment databases to be created and queried. All fragment lengths are supported and any set of PDB files can be used to create a database. Fragger can efficiently search a fragment database with a query fragment and a distance threshold. Matching fragments are ranked by distance to the query. The query fragment can have structural gaps and the allowed amino acid sequences matching a query can be constrained via a regular expression of one-letter amino acid codes. Fragger also incorporates a tool to compute the backbone RMSD of one versus many fragments in high throughput. Fragger should be useful for protein design, loop grafting and related structural bioinformatics tasks.

Nowadays, a large number of protein structures are available (122,761 as of July 2017 at RCSB) and protein fragments are frequently used in structural bioinformatics. Protein structure prediction methods such as Rosetta 1 , QUARK 2 and EdaFold 3,4 use protein fragments as building blocks. Protein fragments are also used in crystallographic phasing 5-7 and model rebuilding 8 . The quality of protein models can be improved by combining protein fragments with molecular dynamics 9 . Other applications include the curation of unresolved loops in crystal structures 10,11 , grafting of loop sequences on protein scaffolds and other protein design algorithms 12,13 .
When there are too many fragments to search from, an efficient strategy is necessary to reach sub-linear search times. This problem is well-known to the chemoinformatics community, which has developed several efficient strategies to screen large databases of small molecules. For example, geometric embedding and locality sensitive hashing 14 , kd-trees 15 , a tree data structure (called µ-tree) with a heuristic 16 , bounds of similarity scores for chemical fingerprints 17 and a proximity filter based on the logical exclusive or operator 18 have all been developed to this end.
Currently, several fragment pickers 19-22 and protein fragment databases 23-28 are available. Of particular interest is the Super method 20 that uses the lower bound of RMSD 29 to screen the whole fragment space. However, our research on protein design and refinement of protein decoys for crystallographic phasing required specific options and therefore a new fragment picker.

end for
{exact query: refine the result of pruning} Fragger exploits the triangular inequality of RMSD 30 to prune the fragment space ( Figure 1 and Algorithm 1). RMSDs are computed efficiently via the QCP method 31 . Fragger is written in OCaml 32 , except backbone RMSD computations which are performed with a new version of the C++ ranker tool from Durandal 33 . Computations are parallelized on multi-core computers via the Parmap library 34 .
Fragger allows a database to be queried with a fragment and an RMSD threshold. Matching fragments are ranked by RMSD to the query. Fragger's ranker tool allows to compute the backbone RMSD of a single fragment versus many. Fragger can deal with residue gaps or a selection of residues from the query, create a fragment database from a set of Protein Data Bank (PDB) files, work with all fragment lengths and extract specific or randomly-chosen fragments from a database.
Compared to existing fragment pickers, some of the specific functionalities required by users include: • Outputing only the N best or N first found fragments matching a query (this can make a query terminate faster)

Amendments from Version 1
Thanks to the referees' recommendations, we have improved our manuscript in this revised version. An extra paragraph was added in the introduction to describe the rationale underlying Fragger. Several citations to web servers and protein fragment databases were added to provide a broader overview of similar approaches. Some variables in the algorithm have been renamed to facilitate easy understanding. A new paragraph and one reference about choosing good reference fragments were added. Several changes were made to clarify the choice of reference fragments, and the impact of the effective cutoff values on search speed.

REVISED
• Constraining the amino acid sequences allowed to match a query (for loop grafting; such filtering is applied after RMSD pruning of the fragment space) • Reading and writing PDB fragments from/to a binary format (faster than reading/writing regular PDB files) • Preventing a list of PDB codes from matching a query • Automatically varying the RMSD threshold to the query until a given number of fragments is reached.

Operation
Users need to install OPAM and the pdbset command from CCP4 in order to use Fragger.
Details on how to install Fragger and usage examples are provided in the README file of the released software.

Results and discussion
Tests were performed on one core of a 2.4GHz Intel Xeon workstation with 12GB of RAM running Ubuntu Linux 12.04. The PDB dataset is composed of all proteins determined by X-ray, without highly similar sequences (30% sequence identity cutoff) in order to create a challenging set of fragments to benchmark a protein design algorithm. It contains 13,554 PDBs. PDBs were extracted from the protein databank website using the advanced search tab and ticking the "Retrieve only representatives at 30% sequence identity" box. Querying with a three (resp. nine) residues fragment takes at least 6.75s (resp. 5.2s).
Query times vary with the query fragment, reference fragments, indexed proteins and RMSD tolerance to the query. In general, the longer the required fragment length and the smaller the RMSD tolerance, the faster the query.
Reference fragments can be chosen randomly. Pruning of the search space is better if there are at least three reference fragments, far from each other. Once a RMSD index has been computed for a randomly chosen fragment (f i ), taking the furthest fragment from it (f j ) and the median fragment (f k ) would give three acceptable reference fragments. For interested contributors, some good heuristics can be found in the literature but were not implemented in Fragger, like Brin's greedy algorithm 35 .
For one time tasks, it is not necessary to create RMSD indices and actually query a database, as fragments extraction and RMSD computations are fast enough. For example, it takes only 15s to generate all (41,200) fragments of 13 residues starting with alanine and ending with glycine (middle of Figure 1). Ranking them to the query takes 1.5s. When working on PDB files, the ranker tool included with Fragger can compute 66,580 (resp. 23,784) RMSD/s on the backbone of three (resp. nine) residue fragments. These numbers become 304,149 (resp. 138,744) RMSD/s when working on Fragger's binary-encoded PDBs.
In the future, it might be possible to improve the performance of Fragger by incorporating a faster score than RMSD, such as BCscore 36 .
Fragger can be useful for protein design, loop grafting and retrieval of candidates to rebuild low-confidence regions of protein models 6 . Figure 1. Left: pruning the fragment space for query distance d q and query fragment q. q is at distance d 1 (resp. d 2 ) from reference fragment r 1 (resp. r 2 ). Only fragments which are both within d 1 ± d q of r 1 and d 2 ± d q of r 2 will undergo an RMSD calculation. Middle: 13 residues loops that can connect residue ALA 98 to GLY 110 in chain A of PDB 1MEL. The query loop is shown in red. Only its first and last three residues were used to rank the retrieved fragments. Right: Backbone of PDB 1BKR covered with ten residue fragments from non-homologous proteins retrieved with Fragger.

Data availability
All data underlying the results are available as part of the article and no additional source data are required.

Competing interests
No competing interests were disclosed.

Grant information
This work was supported by the "Initiative Research Unit" program from RIKEN, Japan, the Japanese Society for the Promotion of Science (JSPS) and computing resources on the RIKEN Integrated Cluster of Clusters (RICC). FB is a JSPS international fellow.
The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
The paper is made up of previously published methods put together as a potentially useful package.
The Super method (mentioned in the introduction of the manuscript) seems to fulfil the same purpose as Fragger. No comparison is provided between the two methods in terms of performance and quality of fragments output.
It is unclear from the Methods section how the reference fragment set is selected. It is mentioned in the Results that these fragments can be selected at random, but the authors never discuss whether this choice can have an impact on the performance of the algorithm.

Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Partly No competing interests were disclosed. Competing Interests: 1 2 1 2 -quickly identify the representative fragments similar to the query in a way to perform effective pruning of the complete collection of fragments, ensuring not discarding the matching fragments, and then perform a systematic search for the fragments of the classes associated with the matching representative fragments.
This kind of approach has been used in several contexts and is interesting. The manuscript however could easily be improved.
Here are some specific comments: -The introduction could benefit from a better description of the rationale underlying Fragger, including its use in different contexts. For instance, such a strategy has also been used for the fast similarity search of small compounds.
-The introduction could benefit from a larger overview of the approaches that have been setup to address questions similar to that of Fragger. There are also a series of web servers focusing on this goal that are not cited.
-The way the algorithm is described makes it rather uneasy to understand. There could first be some awkwardness in the notations. For instance, in the algorithm description, blanks between d and b and between r and f could be discarded. Secondly, it could be difficult for a reader to understand the role of the representative fragments, the way they are identified and used from the present description of the algorithm. Probably an additional flowchart or figure to explain it would be welcome.
-The critical parameters of the procedure are not really identified. What are the effective cutoff values, how do they impact on the search ?
-It seems Fragger offers possibilities to constrain amino acidd sequences. Is it a prior or a posterior filtering ?

Is the rationale for developing the new software tool clearly explained? Partly
Is the description of the software tool technically sound? Partly

Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Partly No competing interests were disclosed.

Competing Interests:
No competing interests were disclosed. Competing Interests:

I have read this submission. I believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.
Author Response 04 Apr 2018 , RIKEN, Japan Kam Zhang > -The introduction could benefit from a better description of the > rationale underlying Fragger, including its use in different contexts. For > instance, such a strategy has also been used for the fast similarity > search of small compounds.
We have added an extra paragraph in the introduction to mention related methods found in chemoinformatics.
> -The introduction could benefit from a larger overview of the > approaches that have been setup to address questions similar to that of > Fragger. There are also a series of web servers focusing on this goal > that are not cited.
We have added several citations to web servers and protein fragment databases which are using various methods.
> -The way the algorithm is described makes it rather uneasy to > understand. There could first be some awkwardness in the notations. For > instance, in the algorithm description, blanks between d and b and > between r and f could be discarded. Secondly, it could be difficult > for a reader to understand the role of the representative fragments, > the way they are identified and used from the present description of > the algorithm. Probably an additional flowchart or figure to explain it > would be welcome.
We have renamed some variables in the algorithm to bypass typographic problems introduced by the journal's style-sheet.
We have also added a new paragraph and one reference about choosing good reference fragments.
> -The critical parameters of the procedure are not really identified. What > are the effective cutoff values, how do they impact on the search ? This is quite complex: the search speed is influenced by the protein database, the fragment length and the query RMSD tolerance. In the manuscript, we now summarize the general trend as: "In general, the longer the required fragment length and the smaller the RMSD tolerance, the faster the query.". > -It seems Fragger offers possibilities to constrain amino acidd > sequences. Is it a prior or a posterior filtering?
We updated the manuscript to indicate that this is done after geometric filtering.
No competing interests were disclosed.

Competing Interests:
The benefits of publishing with F1000Research: Your article is published within days, with no editorial bias You can publish traditional articles, null/negative results, case reports, data notes and more The peer review process is transparent and collaborative Your article is indexed in PubMed after passing peer review Dedicated customer support at every stage For pre-submission enquiries, contact research@f1000.com