Propose an optional HADDOCK3 provider through a reusable public docking API

Aperta
  • Qualcosa non va?
#109 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend-api-design, distributed-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
1
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di uibcdf/dockingmt

Tutte le issue di uibcdf/dockingmt

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.