Propose an optional HADDOCK3 provider through a reusable public docking API

Đang mở
  • Có gì không ổn?
#109 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
backend-api-design, distributed-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
1
Fork
0
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của uibcdf/dockingmt

Tất cả issue của uibcdf/dockingmt

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.