Propose an optional Boltz-2 provider through a public complex-prediction API

オープン
#110 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
api, backend

調査の方向性

Start with the referenced DockingProblem and pose recovery code at commit e01391cc218fd32d4494817ab91f98eaa4f426b5, then review the unresolved cofolding discussion in #33 and the pinned Boltz prediction contract. The issue asks owners to agree on a reusable fixed-identity complex prediction API, result changes, supported inputs, mappings, and failure behavior; no exact API or schema is prescribed. Done means the owners agree on that contract and workflow, with the listed controls, terms, and pilot reviews still subject to their stated separate gates.

索引モデルが issue の本文から書いたものです。

説明

component:molsysmt component:peptidemt needs-triage proposal

PeptideMT needs fixed-sequence complex predictions as structural hypotheses that can subsequently be completed and assessed on the declared full chemical system. Please review Boltz-2 as an optional provider of a general public complex-prediction operation, available directly to researchers and reusable beyond peptide workflows.

This is joint complex prediction: it may generate coordinates for every partner. Its scientific input/output promise should remain distinct from docking prepared structures, even if both operations belong to DockingMT's binding domain. Simply adding a backend name to a Vina-shaped call would not receive that difference.

Related proposals: component name/scope #108 and HADDOCK3 physical docking #109. This operation remains distinct and can be reviewed under the current component identity.

Existing context and architectural proposal

Continue the unresolved cofolding/provider discussion in #33, with PeptideMT #33 as the consumer question.

At inspected e01391cc218fd32d4494817ab91f98eaa4f426b5, normal molecular receiving in DockingProblem requires coordinates, while pose recovery uses partner topology/maps. A received sequence-input, moving-receptor multichain provider is still missing.

Proposed owner: DockingMT for the scientific complex-prediction operation and optional adapter; MolSysMT for molecular identity/preparation/conversion/maps; PeptideMT for peptide design/selection/interpretation. Praxis retains methodology/applicability/selection under #18 and MolI #84. This ownership/public-interface proposal needs owner agreement; no exact API name or schema is prescribed.

Public contract to design

  • Receive fixed molecular identities, including sequence-based inputs and structural information when available, with an explicit supported representation profile. Define molecular/chain roles and maps through MolSysMT-owned receiving.
  • Allow structure-free inputs when supported. Do not impose PDBQT, a Vina box, a pre-existing ligand pose or an unchanged receptor on a joint predictor.
  • Make MSAs, pairing/cropping, database identities, templates, template forcing, constraints and other priors explicit. Remote acquisition and disclosure must be an informed selected route; supplied/saved inputs remain independently usable.
  • Pin Boltz model family/checkpoint, code, adapter and runtime separately. Record resolved recycles, diffusion steps/samples, seeds, batching, precision/kernels and devices; preserve unavailable/incompatible profiles and measured resource outcomes without silent method/precision substitution.
  • Preserve the complete predicted complex, all partner coordinate/frame changes, chain/residue/atom correspondences, missing/generated atoms and original processed/native outputs.
  • Preserve native confidence files with their original scale, units and chain/pair/token granularity, missingness and ranking semantics. Scientific result extensions may be necessary; a shared technical receipt does not require flattening everything into a ligand-coordinate/energy record.
  • Keep runtime/weights optional and isolated. Importing the core component or reading saved predictions must not require model loading, CUDA, downloads or a remote service.
  • Distinguish unsupported molecular representation/applicability, missing dependencies, preparation/transport failure, runtime/resource failure and incomplete/unparseable output.

PeptideMT need: native prediction to complete chemistry

The initial consumer question is fixed-identity MDM2–p53 pose modelling, not sequence generation. We have a declared capped/state/stereo target hypothesis; full preparation remains with MolSysMT #685.

Incomplete native chemistry alone must not exclude a provider. Use exact target chemistry where supported. Otherwise preserve the native approximation and receive a traceable route to the full target system through MolSysMT completion and separately selected refinement/evaluation. Original confidence belongs to the original prediction; reconstructed atoms and changed coordinates do not automatically inherit it. Keep native, completed and refined artifacts distinct, with explicit failed-completion outcomes.

Reference peptide coordinates are evaluation-only. A successful 1YCR case is exposed-reference technical/structural evidence, not an independent benchmark or demonstrated affinity.

The initial operation is structure prediction only. Boltz's documented affinity head is scoped to a small-molecule ligand and does not establish peptide Kd applicability. Single-chain folding, affinity prediction and conformational sampling require their own scientific scope/owner reviews; adding this adapter does not admit all Boltz functionality.

Acceptance proposal

  • Agree the reusable fixed-identity complex contract, admitted modalities/chemistry, mappings, failure behavior and minimal owner API/result changes.
  • Document a generic researcher workflow usable without PeptideMT, with separate scientific meanings for structure, confidence and any future affinity outputs.
  • Receive small frozen/saved-output controls for multichain coordinates, moving receptor, nontrivial mappings, partial chemistry, confidence and fresh replay; keep absence tests independent of Torch/GPU.
  • Review exact code/weight terms, acquisition/cache policy, disclosure, device/precision requirements and supervision before a bounded live pilot.
  • Under separate execution authority, compare adapter outputs with direct upstream execution and report measured fit/numerical limitations without promising hardware compatibility.
  • Receive PeptideMT's composition separately and retain pre/post-completion assessments.

Upstream: pinned prediction contract, code/weight terms, primary technical report.

This is an owner-review proposal, independent of the rename and existing release gates. It commissions no implementation, model/weights acquisition, GPU use, scientific campaign or general-purpose AI framework.

主要言語
Python
スター
1
フォーク
0
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

uibcdf/dockingmt のほかの issue

uibcdf/dockingmt の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。