Propose an optional HADDOCK3 provider through a reusable public docking API

Open
  • Is something wrong?
#109 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend-api-design, distributed-systems

Research direction

Start by reading devguide/ENGINES.md and the existing backend records at the inspected source revision to identify what the public docking operation and provider adapter must cover. Review the listed scientific obligations and owner boundaries, then propose a reusable operation/profile, supported domain, and failure model without freezing signatures or classes. Done means the owners agree on that contract and its acceptance criteria; implementation and execution are explicitly outside this proposal.

Written by the indexing model from the issue text.

Description

component:molsysmt component:peptidemt needs-triage proposal

PeptideMT needs a supported physical protein–peptide pose route, while DockingMT's received reference profile is Vina-oriented. Please review an optional HADDOCK3 integration exposed through a general public docking API, usable directly by researchers and by consumers beyond PeptideMT.

The public contract should express the scientific operation; HADDOCK3-specific invocation/configuration belongs in its optional adapter. MDM2–p53 is an initial consumer case, not a hard-coded target or the definition of the API.

Related naming proposal: #108. This provider can be reviewed under the current component identity.

Existing context and ownership

This focused proposal continues the peptide-provider need in #33, including the earlier HADDOCK3 handoff. It separates future provider work from that issue's chemical/native-format receiving.

At inspected source e01391cc218fd32d4494817ab91f98eaa4f426b5, the backend supports docking/optional scoring and the supplied engine family remains Vina. The engine strategy already allows specialized peptide engines and multi-provider protocols. No HADDOCK3 profile is claimed received by this request.

DockingMT owns operation/protocol/adaptation and faithful results. MolSysMT owns molecular preparation, representation, conversion and correspondence. PeptideMT owns scientific eligibility, permitted information, selection and interpretation. Follow MolI #84 and Praxis #18; expert use should remain possible without PeptideMT or an agent.

Public contract to design

  • Accept declared molecular partners, prepared chemical states and optional input conformer ensembles through owner-supported molecular representations. Record source identities, selections, units and coordinate frames.
  • Represent site/restraint information and flexibility explicitly. Preserve the source of restraints, starting conformations and any approximation; PDBQT or a Vina search box must not become compulsory for this provider.
  • Record resolved stage configuration, seeds, requested/effective sampling counts, software/CNS/topology identities and bounded CPU/thread/time/output settings, including per-module overrides.
  • Preserve all predicted partner coordinates, including receptor changes, with explicit source/prepared/backend/output maps and generated/removed atoms.
  • Return faithful native stage outputs, scores, clusters and ranks with definitions, units where defined, producer and ranking direction. A composite HADDOCK score must not acquire invented energy units or experimental-affinity meaning.
  • Support useful saved-output inspection/replay independently of the installed engine. Preserve absence, unsupported chemistry, preparation failure, execution/resource failure, partial output and parse failure distinctly.

Do not freeze signatures/classes in this issue; review suitable existing records and the minimal extensions needed for these scientific obligations.

PeptideMT's concrete need

For an initial fixed-identity MDM2–p53 study, receive a declared capped linear-peptide/receptor hypothesis with protonation/stereo provenance, independent non-native peptide starts, declared receptor/site information and traceable outputs. The native reference peptide coordinates are evaluation-only.

The accepted consumer direction is to use each provider at its supported chemical resolution and work toward the declared complete target system. Preserve native predictions and omissions, then perform mapped MolSysMT-owned completion and suitable refinement/evaluation. Completion alone does not prove a better pose; compare raw and transformed results separately. Current full preparation still awaits MolSysMT's owner route under #685.

Pose geometry, native ranking/confidence, measured affinity and useful peptide selection are separate questions. The known 1YCR case can receive a workflow but cannot establish independent generalization.

Acceptance proposal

  • Agree the reusable operation/profile, supported chemical/partner domain, failures and owner responsibilities.
  • Provide public documentation and generic examples that require neither PeptideMT nor MDM2-specific code.
  • Exercise absent-engine independence, saved-result receiving, faithful maps/units/rank semantics and meaningful controlled fixtures.
  • After a separately reviewed bounded execution plan, compare the installed adapter with a direct upstream invocation; retain exact inputs/configuration/native outputs and any unsupported outcome.
  • Report qualified profiles and scientific limits explicitly; add a PeptideMT consumer receiving separately.

Upstream evidence: official peptide guide, HADDOCK3 source, and separate CNS terms. Supporting an optional provider does not imply redistributing CNS or installing it with core DockingMT.

This is an owner-review proposal, independent of the naming decision and existing release gates. It authorizes no implementation, installation or scientific campaign by itself.

Dominant language
Python
Stars
1
Forks
0
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uibcdf/dockingmt

All issues in uibcdf/dockingmt

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.