iSARST: an integrated SARST web server for rapid protein structural similarity searches

30-second read

iSARST combines SARST/CPSARST filtering with FAST, TM-align, and related refiners in a batch-oriented multiprocess web workflow.

Central question

How can fast structural screening, accurate 3D alignment, batch submission, and parallel computing be composed into a responsive structure-search service?

Intuition

iSARST resembles two-stage airport screening: SARST/CPSARST rapidly narrows the crowd, then distributes a small candidate set to FAST, TM-align, or SAMO for detailed checks. A master node collects RMSD, alignment size, and similarity scores and reranks the hits.

Why it matters

Its contribution is not another standalone alignment objective but a system architecture that decouples high-recall screening from high-quality refinement, allowing multiple engines to share batch, cache, and interactive workflows.

Prerequisites

• Understand SARST and CPSARST structural-string screening.
• Recognize FAST, TM-align, and SAMO as different refinement engines.
• Know master/worker parallel task distribution and caching.
• Distinguish recall, precision, RMSD, alignment size, and runtime.

paper-specific guide · plain → technical → input → output → source

Method walkthrough

1. 01 · Build a raw hit list with SARST/CPSARST

   Convert the query to a Ramachandran string and obtain high-recall candidates from pre-encoded PDB/SCOP databases.

   Technical reading: Co-linear search uses SARST directly, while CP search uses normal-/duplicated-length CPSARST screening; both scan RM-string databases through blastall.

   Input: One or more PDB/SCOP IDs, a PDB file, or an archive containing multiple structures.

   Output: An unrefined hit list of co-linear or CP candidates.

   Boundary: Screening order is not the final 3D-similarity order.

   PDF pp. 2–4, Methods and Figure 1

2. 02 · Distribute pairwise refinement across worker nodes

   Treat each candidate pair as an independent task and evaluate many tasks concurrently.

   Technical reading: The master scatters hits to workers that align them with user-selected FAST, TM-align, or SAMO. MPI C/PHP distributes tasks according to node response and thread count, then collects RMSD, alignment size, and structural scores.

   Input: A raw hit list and selected refinement engine.

   Output: Refined geometric quantities for each query–hit pair.

   Boundary: Parallelization reduces wall-clock time but does not change the called aligner's objective or accuracy ceiling.

   PDF pp. 2–4, Methods, Figure 1 and multi-processor implementation

3. 03 · Rerank, cache, and inspect interactively

   The master reranks by refined scores, caches repeated queries, and exposes structural, functional, and CP views.

   Technical reading: The hit list can be sorted by RMSD, alignment size, structural diversity, sequence identity, or function; superpositions can be downloaded or rotated and restyled in an interactive viewer.

   Input: Refined results, annotations, and cached sessions.

   Output: Final hit tables, functional summaries, and visualized superpositions.

   Boundary: Caching improves repeated-query latency and must not be conflated with first-run computation time.

   PDF pp. 5–6, Figure 2 and Web Server Description

Key result

The paper operationalizes filter-and-refine, retaining refiner quality while avoiding exhaustive detailed comparisons.

Evidence-guided deep reading

Paper facts, project readings, and teaching models are labelled separately.

paper-fact

The novelty is orchestration, not replacing FAST

Figure 1 explicitly separates screening and refinement: the query becomes an RM string for SARST/CPSARST hit retrieval, after which FAST, TM-align, or SAMO computes detailed structural similarity and reranks.

Thus, “iSARST preserves the refinement engine's precision” is a system-composition result. When FAST is selected, part of the quality claim is FAST's quality rather than a new, superior pairwise objective invented by iSARST.

Source locator: PDF pp. 2–4, Methods and Figure 1

paper-fact

Hit-list size controls recall and cost

Table 1 tests 34,055 SCOP domains: 100 hits give 75.4% average recall, 500 give 85.1%, 5,000 give 93.9%, and all 34,055 give 100%. More candidates reduce the risk of missing relevant structures.

With 80 processors and FAST refinement, 500 hits average 7.78 seconds, while all 34,055 take 320.89 seconds. The paper notes that a single-machine run can be about 60 times longer, so timings must be reported with hardware and parallelism.

Source locator: PDF pp. 4–5, Table 1 and Experiments

project-reading

Evaluate latency, throughput, and quality separately

First-query latency combines encoding, screening, task distribution, and refinement; batch throughput depends on worker count; repeated-query latency additionally depends on cache. These should not collapse into one vague notion of speed.

Quality also needs a level: screening uses recall, final ranking uses precision or downstream utility, and pairwise geometry uses RMSD/alignment size. Only then can an improvement be attributed to the correct stage.

Source locator: PDF pp. 4–6, Table 1, Experiments and Web Server Description

Study design and evaluation

Data and samples

Information-retrieval experiments use the same 34,055-domain SCOP target database as earlier SARST work and vary raw hit-list size; 80 processors share refinement. Multiple simultaneous clients additionally test concurrent-user behavior.

Baselines

• FAST, TM-align, and SAMO serve as alternative refinement engines; exhaustive one-against-all refinement and smaller candidate sets provide cost contrasts.

Metrics

Average recall

How many relevant structures survive in the raw hit list before refinement.
Boundary: Depends on SCOP relevance and hit-list size and does not measure geometric superposition quality.

Average precision

The proportion of relevant hits after refinement.
Boundary: The paper claims preservation of the selected refinement engine's precision, not superiority over it.

Wall-clock runtime

Average seconds for different hit-list sizes and refinement engines on 80 processors.
Boundary: Not directly comparable with single-machine, different-worker-count, or cache-hit results.

Reported result

A 500-hit setting reaches 85.1% average recall. With FAST, 80 processors complete 500 pair superpositions in 7.78 seconds on average, and at 85.0% recall the average precision is 85.2%, equal to the cited FAST evaluation.

PDF pp. 4–5, Table 1 and Experiments

teaching-model · not a reported experiment

Teaching example (not a reported experiment)

Choose how many hits to refine

Project teaching model: screening returns 10,000 candidates, but an interactive budget can afford only 500 detailed superpositions.

1. Use a validation set to plot screening recall against hit-list size.
2. Choose an acceptable knee point within the latency budget, such as 500 hits, rather than an arbitrary constant.
3. Distribute 500 pairs to workers, rerank with one refinement engine, and report first-run latency, batch throughput, and cache-hit latency separately.

Takeaway: Candidate-set size controls the recall–cost tradeoff; parallelism changes the cost curve but does not eliminate screening false negatives.

historical-ecosystem

Evidence boundary versus FAST

FAST is an optional iSARST refinement engine, so part of the output quality is inherited from FAST; system-level speedup is not proof of a better alignment objective.

Lawful source and access

7 pages · SHA-256 7bc0fa61a5fa9eb9e03dda61c281fa8c42789f587fe541637e4af42c325a8943

Lawful open full text.

Europe PMC open-access PDF

Limits and misreadings

• Performance is constrained by external BLAST and refiner invocations.
• The legacy web/PHP architecture does not scale naturally to hundreds of millions of structures.

Source locator map

1. PDF pp. 1–2, Abstract and system motivation
2. PDF pp. 2–4, Methods and Figure 1
3. PDF pp. 4–5, Table 1 and Experiments
4. PDF p. 5, Figure 2
5. PDF pp. 5–6, Web Server Description

Check understanding

1. What determines iSARST's final ranking?

   Answer: It is reranked by results from the selected refinement engine, such as FAST, TM-align, or SAMO.

   SARST/CPSARST first determine the candidate set, not the final geometric order.

2. Does adding processors increase screening recall?

   Answer: Not directly; it mainly shortens refinement wall-clock time.

   Recall mainly depends on representation, search parameters, and hit-list size.

3. Which condition is essential for reproducing the 7.78-second result?

   Answer: Conditions including 500 hits, FAST refinement, the 34,055-domain benchmark, and 80 processors.

   Runtime must be bound to workload, engine, and hardware.

Completion task: Write a three-layer acceptance table for a modern iSARST-like service: for screening, refinement, and serving, list the dataset, metric, hardware conditions, and non-extrapolatable boundary.

Paper-specific glossary

Raw hit list

A candidate list produced by screening before detailed 3D reranking.

Refinement engine

A tool that performs detailed structural alignment on candidate pairs and produces final ranking quantities.

Wall-clock time

Elapsed user-perceived time, which changes with parallelism.

Cache

Stored prior results that avoid recomputation for repeated queries.