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

Aperta
  • Qualcosa non va?
#110 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
api, backend

Direzione di ricerca

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.

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

Descrizione

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.

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.