Propose an optional Boltz-2 provider through a public complex-prediction API
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from uibcdf/dockingmt
-
component:molsysmt component:peptidemt component:pharmacophoremt component:topomt needs-triage proposal
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
component:molsysmt component:peptidemt component:pharmacophoremt component:topomt needs-triage proposal
Difficulty 5/5 Over a week Newbie friendliness 24/100
-
component:molsysmt component:peptidemt needs-triage proposal
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
bug component:argdigest component:molsysmt component:molsysviewer
Difficulty 5/5 Over a week Newbie friendliness 1/100
-
component:molsysmt component:molsysviewer component:pytest-receptor partial proposal
Difficulty 5/5 Over a week Newbie friendliness 20/100
All issues in uibcdf/dockingmt
Similar issues
-
area:core-platform effort:S priority:P3 risk:night-safe status:ready type:test
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
randomparity/kdive#3620 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
FinanceFlash/unvibecode#760 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
google-research/google-research#3470 ·
Maintainers usually reply within 21 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
mrvautin/ha-workouts#11 ·