Propose an optional HADDOCK3 provider through a reusable public docking API

Abierto
  • ¿Algo no está bien?
#109 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend-api-design, distributed-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
1
Forks
0
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de uibcdf/dockingmt

Todos los issues de uibcdf/dockingmt

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.