Complexa Sweep
NVIDIAOfficialCreated by Ohad MosafiDistributed by NVIDIA
- Skill
- Workflow
- Science and research
- Apache-2.0
- Medium risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The complexa-sweep skill provides a structured runbook for executing systematic parameter sweeps over Proteina-Complexa design pipelines. It automates the generation of multiple inference configurations based on a sweeper YAML, manages the execution loop across these configurations, and aggregates results into a ranked summary. This process enables users to perform ablations, tuning, and Pareto searches over quality and computational cost metrics, ensuring consistent evaluation across diverse parameter sets.
What it does
- Generates multiple inference configurations from a cartesian-product sweeper YAML.
- Executes the design pipeline across a generated grid of parameter combinations.
- Aggregates per-config success metrics into a ranked summary CSV.
- Identifies the best-performing configuration and Pareto frontiers.
- Provides a manifest for result tracking and experiment reproducibility.
- Includes pre-flight checks to estimate GPU budget and hardware readiness.
When to use it
- When performing hyperparameter tuning or ablations on design pipelines.
- When comparing multiple search algorithms or model configurations.
- When conducting Pareto searches to balance design quality against wall-clock time.
- When you need to rank configurations based on success rates and diversity metrics.
Advantages
- Systematic exploration of parameter space via cartesian-product enumeration.
- Automated aggregation of results simplifies complex multi-run analysis.
- Supports multi-GPU sharding for efficient execution of large sweeps.
- Provides clear visibility into cost and resource requirements before execution.
Usage examples
- “Run a sweep over beam_width and nsteps for the 22_DerF21 task.”
- The agent will generate the necessary inference configs using the specified sweeper YAML, execute the design pipeline for each combination, and produce a ranked sweep_summary.csv.
- “Estimate the GPU cost for a 4-axis sweep with 4 values each.”
- The agent will calculate the total number of configurations and estimate the total GPU-hours based on the per-run baseline, prompting for confirmation before proceeding.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/complexa-sweep/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip complexa-sweep.zip -d .agents/skills
Documentation by Ohad Mosafi
complexa-sweep
Run cartesian-product parameter sweeps over Proteina-Complexa design pipelines. Pick or author a sweeper YAML in configs/sweeps/, expand it to N inference configs with script_utils/generate_inference_configs.py, loop complexa design over those configs, then aggregate per-config success metrics into a ranked summary CSV plus a manifest.
Important: The
complexa designCLI does NOT accept--sweeperdirectly. Sweeps are driven byscript_utils/generate_inference_configs.py, which writes oneconfigs/inference_configs/inf_{idx}_{run_name}.yamlper sweep combination. You then loopcomplexa designover those generated configs.
Instructions
Sweeper authoring, Cartesian enumeration, cost estimates, and analysis of supplied CSVs need only the relevant configs and data. Complete those artifacts without setting up inference. Read the relevant axis section in sweep_axes.md, then check the matching keys in the selected source config for current defaults. Summary CSVs with supplied counts and objective columns do not require the full inference or metric guides. For a partial snapshot, enumerate combinations locally and provide the future generator command; running that command requires the full project and its dependencies.
For a requested launch, check readiness and the budget below. A single existing job or a SLURM template does not require a parameter sweep.
Step 1: Pre-flight
Before GPU execution, or when the request conditions its workflow on hardware,
set SKILL_DIR to the directory containing this manifest and run preflight once.
Use a separate shell assignment; an inline environment assignment cannot set
$SKILL_DIR's expansion in the same command.
Reuse an existing probe from the same request if the environment is unchanged:
bash "$SKILL_DIR"/scripts/preflight.shRead ./complexa_setup/preflight.json. A sweep multiplies GPU time by the number
of configs and targets. Compute the budget before launch and obtain confirmation
if the user has not already authorized that scope and cost:
"This sweep produces N configs × ~M minutes per config ≈ TOTAL GPU-hours. OK to proceed? (y / reduce / cancel)"
If gpu.available=false, stop before GPU execution. Sweeper authoring,
Cartesian-product enumeration, cost estimates, and analysis of supplied CSVs
can run on CPU. For those requests, finish the requested artifacts and record
the launch prerequisites. Label synthetic input data as synthetic and keep
estimated GPU time separate from measured runtime.
For a hardware-conditional request, verify the allocated hardware before
selecting the CPU fallback. Missing weights, dependencies, or sufficient VRAM
for an allocated GPU are launch blockers, not evidence of a CPU-only environment.
Report probe or execution failures without reclassifying the selected branch.
The shared preflight's gpu.available=false also covers failed or missing
nvidia-smi; check device/allocation evidence before treating it as GPU absence.
In containers, /proc/driver/nvidia/gpus and loaded kernel modules may describe
the host, not this task's allocation. Check container device exposure and any
available scheduler allocation information together. A CPU allocation can share
a GPU host; an allocated GPU with inaccessible devices is blocked. If allocation
remains unclear, report it as undetermined.
Step 2: Pick the pipeline + target
Use the user's supplied pipeline, targets, and run name. Protein, ligand, and AME
runs use search_binder_local_pipeline, search_ligand_binder_local_pipeline,
and search_ame_local_pipeline, respectively. Ask only for missing values:
pipeline_config_name— e.g.search_binder_local_pipeline(default),search_ligand_binder_local_pipeline,search_ame_local_pipeline.task_name— e.g.02_PDL1,22_DerF21,39_7V11_LIGAND. Passed as--override generation.task_name=<task>.run_name— short tag for output dir naming.
Examples
Step 3: Pick or author the sweeper YAML
Sweeper YAMLs live in configs/sweeps/. Each key is a dot-notation Hydra path; each value is a list. The cartesian product becomes N configs.
Canned sweepers
| File | Axis | Values | Configs |
|---|---|---|---|
configs/sweeps/beam_width.yaml | generation.search.beam_search.beam_width | 1, 2, 4, 8 | 4 |
configs/sweeps/bb_ca_temperature.yaml | generation.model.bb_ca.simulation_step_params.sc_scale_noise | 0.1, 0.4 | 2 |
configs/sweeps/search_replicas.yaml | generation.search.best_of_n.replicas | 1, 4, 16, 64 | 4 |
configs/sweeps/example.yaml | beam_width × nsteps | (2,4) × (200,400) | 4 |
Use a matching sweeper, then check that its axes affect the selected algorithm.
The binder config defaults to best-of-n: a beam-width sweep must also pin
generation.search.algorithm: [beam-search]. A replicas sweep pins
generation.search.algorithm: [best-of-n]. For AME, reward-guided search also
requires a configured reward model; its default is null.
Authoring a new sweeper
Minimal multi-axis example (saved to configs/sweeps/my_sweep.yaml):
# 3 beam widths × 2 nsteps = 6 configs
generation.search.algorithm: [beam-search]
generation.search.beam_search.beam_width:
- 2
- 4
- 8
generation.args.nsteps:
- 200
- 400Rules (from script_utils/generate_inference_configs.py:load_sweeper_file):
Top-level mapping only. Keys are dot-notation Hydra paths.
Keep budgets, launch status, and other planning metadata in the launch plan, outside the sweeper. Every top-level entry becomes an override axis; a separate
targetslist would multiply the grid again.Values must be lists. A scalar is auto-wrapped into a single-element list (which pins a value without adding a dimension).
For a list-valued parameter, nest each candidate list:
metric.sequence_types: [[self, mpnn]]pins one list. The flat form sweeps two strings;--overrideparses scalars only.Cartesian product: total configs = product of list lengths. Multiply by the number of targets unless target names are already one of the axes; do not count them twice.
If a key appears in both the sweeper file and an
--override, the override wins and that axis collapses.Reject empty axes before launch: an axis of
[]produces zero configurations.
See references/sweep_axes.md for the full catalogue of swept keys (typical ranges, cost multipliers, what improves/regresses).
Dry-run preview before generating
With the full project available, confirm the config count first:
python script_utils/generate_inference_configs.py \
--config_name search_binder_local_pipeline \
--sweeper configs/sweeps/my_sweep.yaml \
--override generation.task_name=22_DerF21 \
--run_name my_sweep \
--dryrunThe output lists every axis + value list and prints DRY RUN — would generate N config pair(s).
This previews enumeration only; it returns before Hydra composition and does
not validate the pipeline, parameter types, or launch prerequisites.
When the full project is available, inspect the materialized inference configs before launching. Check the resolved target, selected search algorithm, and requested parameter values across the generated grid. The generator permits unknown keys during merging, so a successful write alone does not establish that a misspelled or misplaced axis changes the intended parameter. With only a partial snapshot, check each dot-path against its source config and report that materialization remains unverified.
Step 4: Generate configs + loop complexa design
Once the dry-run looks right, drop --dryrun to materialize inf_{idx}_{run_name}.yaml + eval_{idx}_{run_name}.yaml pairs under configs/inference_configs/ and configs/eval_configs/. Then loop complexa design over the inference configs.
For multiple targets, put generation.task_name in the sweeper as an axis, or
give each target's generator invocation a distinct --run_name. Indices restart
at zero on each invocation and filenames omit the target; reusing the same run
name and output directories overwrites earlier configs and reuses result paths.
# 1. Generate one inf_*.yaml + one eval_*.yaml per combination.
python script_utils/generate_inference_configs.py \
--config_name search_binder_local_pipeline \
--sweeper configs/sweeps/my_sweep.yaml \
--override generation.task_name=22_DerF21 \
--run_name my_sweep
# 2. Loop complexa design over each generated inference config.
for cfg in configs/inference_configs/inf_*_my_sweep.yaml; do
complexa design "$cfg" || echo "FAILED: $cfg"
doneThis serialises the sweep on a single GPU — be honest with the user that wall-clock = N × per-run.
Multi-GPU host (optional speed-up)
On a host with K GPUs, shard the config list K ways and launch one loop per GPU in parallel. Each complexa design call uses exactly one GPU at default gen_njobs=1 / eval_njobs=1, so pinning via CUDA_VISIBLE_DEVICES keeps them from colliding:
CONFIGS=(configs/inference_configs/inf_*_my_sweep.yaml)
N=${#CONFIGS[@]}; K=4 # 4 GPUs
for gpu in $(seq 0 $((K-1))); do
(
for i in $(seq $gpu $K $((N-1))); do
CUDA_VISIBLE_DEVICES=$gpu complexa design "${CONFIGS[$i]}" \
|| echo "FAILED on GPU $gpu: ${CONFIGS[$i]}"
done
) &
done
waitDrop gen_njobs / eval_njobs overrides into the loop only if you intentionally want each complexa design invocation to consume multiple GPUs (and you have a way to keep them out of each other's way).
Step 5: Collect results
Each swept config writes to its own ./inference/inf_{idx}_{run_name}/ directory; the analyze step writes ./evaluation_results/eval_{idx}_{run_name}/results_*.csv. After the sweep finishes:
ls -d ./inference/inf_*_my_sweep/
ls ./evaluation_results/eval_*_my_sweep/results_*.csvInspect the supplied CSV schema before aggregating. If it already contains one
row per configuration with n_passed and n_designs, compute
success_rate = n_passed / n_designs; flag zero denominators and invalid counts.
Do not treat those summary rows as individual designs. For per-design rows,
use existing pass flags, parsing string booleans explicitly. If flags are absent,
use the run's analysis thresholds, result_type, column names, and units from
EVALUATION_METRICS.md. PAE may be normalized
by 31 and pLDDT may use different scales; do not substitute generic thresholds.
Step 6: Rank configs
Emit sweep_summary.csv to the run directory. One row per config:
| Column | How to compute |
|---|---|
config_id | The {idx} from inf_{idx}_{run_name} |
<axis_1>, <axis_2>, ... | The swept value at this combination (read from the per-config inf_*.yaml) |
n_samples | n_designs for a supplied config summary, otherwise per-design row count |
success_rate | n_passed / n_designs for a config summary, otherwise mean of parsed per-design pass flags |
mean_i_pae | Preserve the supplied config mean, or average per-design values in consistent units (lower = better) |
mean_i_plddt | i_plddt.mean() (higher = better) |
diversity_score | Unique sequence count / n_samples (or use TM-score clustering if available) |
wall_clock_min | From the per-config log timestamps |
Populate only metrics present in the inputs or computable from them. Missing diversity or timing data stays unavailable.
Then report:
Best config = argmax of
success_rate. Tie-break onmean_i_pae(lower).Pareto frontier: choose the requested objectives and directions. For time versus success, minimize time and maximize success; for time versus iPAE, minimize both. A point is dominated when another is no worse on every objective and strictly better on at least one. Keep distinct config IDs at equal nondominated coordinates; report invalid/missing measurements separately.
Save the full table to sweep_summary.csv, then reopen the saved results and
print a compact summary: row count, best config and metric values, and frontier
IDs with their objective values. Report the CSV paths and keep the hardware
probe and configuration dumps separate from this result summary.
Step 7: Emit manifest
Capture the resolved invocation + outputs for replay. The shared helper takes a single --output-dir (it walks for CSVs and pulls the Hydra config from the run's .hydra/), so call it against the best-config's evaluation directory and pass the parent complexa design command for that run:
BEST_ID=4 # from Step 6 ranking
python3 "$SKILL_DIR"/scripts/write_manifest.py \
--output-dir ./evaluation_results/eval_${BEST_ID}_my_sweep \
--command "python script_utils/generate_inference_configs.py --config_name search_binder_local_pipeline --sweeper configs/sweeps/my_sweep.yaml --override generation.task_name=22_DerF21 --run_name my_sweep && for cfg in configs/inference_configs/inf_*_my_sweep.yaml; do complexa design \"\$cfg\"; done" \
--skill complexa-sweep \
--out ./sweep_runs/my_sweep/sweep_manifest.jsonAlongside the manifest, save the ranked sweep_summary.csv from Step 6 to ./sweep_runs/my_sweep/sweep_summary.csv and surface both paths to the user.
Recommended sweep recipes
| Symptom | Sweep this | Why |
|---|---|---|
| Quality not good enough | beam_width × nsteps (use example.yaml as a starting point) | Both raise compute → quality; find the cheapest combination that lands. |
| Too slow / want speed-up | nsteps downward (e.g. [100, 200, 400]) with fixed beam_width=4 | Find the smallest nsteps that retains success rate. |
| Mode collapse / low diversity | generation.model.bb_ca.simulation_step_params.sc_scale_noise (use bb_ca_temperature.yaml) | Higher noise → more diverse backbones. |
| Reward over-fitting (high reward, bad metrics) | generation.reward_model.reward_models.af2folding.reward_weights.{i_pae, plddt} ratio | Re-balance composite reward. |
| Broaden the best-of-N candidate pool | search_replicas.yaml (best_of_n.replicas) | More candidates per search; use separate seeds/runs to measure repeatability. |
| Algorithm shoot-out | generation.search.algorithm over [single-pass, best-of-n, beam-search, fk-steering] | Compare search regimes; pin everything else. |
Hardware
Total GPU-time for a sweep = N_configs × per_run_GPU_time. A single search_binder_local_pipeline run on one A100 is roughly 30–90 min (binder length + nsteps dependent). A 4-axis × 4-value sweep = 256 configs × ~60 min = ~256 GPU-hours — at that scale, plan on a multi-GPU host with the Step-4 sharding pattern.
Refer to references/hardware.md for the per-run baseline + VRAM minima.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
Sweeper file not found from generate_inference_configs.py | Path resolved from wrong CWD | Use a path relative to the repo root; or pass an absolute path. |
Sweeper YAML must be a mapping | Top-level YAML is a list or scalar | Rewrite as key: [v1, v2] mapping. |
| Dry-run reports zero config pairs | One of the value lists is empty [] | Supply at least one value before generating or launching; the generator does not reject an empty product. |
complexa design rejects --sweeper | Confusion between entrypoints | The CLI does not accept --sweeper. Use generate_inference_configs.py first, then loop complexa design over the generated configs. |
| Override silently collapses a sweep axis | --override key=v shadowed a sweep key | Drop either the override OR the matching key from the sweeper file. |
| One config in the loop fails, sweep keeps going | The || echo "FAILED…" in Step 4 swallows the error | Re-run the failed inf_*.yaml standalone; check the per-config log under ./logs/. Skip failed config_id when ranking. |
For per-axis reference (typical ranges, cost, what gets better/worse), see references/sweep_axes.md.
For the user-facing sweep system overview (config generation, output layout), see references/SWEEP.md.
Files
- ATTRIBUTION.mdAdded by AutoGineer955 B
- BENCHMARK.md7.9 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md16.5 KiB
- config/skillspector-baseline.yml1.2 KiB
- evals/evals.json34.9 KiB
- evals/files/launch_review/launch.shScript586 B
- evals/files/launch_review/sweeper.yaml89 B
- evals/files/pareto_results.csv84 B
- evals/files/project/SNAPSHOT.md1.0 KiB
- evals/files/project/configs/pipeline/binder/binder_generate.yaml9.0 KiB
- evals/files/project/configs/pipeline/model_sampling.yaml1.4 KiB
- evals/files/project/configs/search_binder_local_pipeline.yaml1.5 KiB
- evals/files/project/configs/sweeps/example.yaml1.1 KiB
- evals/files/project/script_utils/generate_inference_configs.pyScript15.1 KiB
- evals/files/project/source_manifest.json670 B
- evals/files/summary_review.csv297 B
- evals/files/sweep_results.csv322 B
- references/CONFIGURATION_GUIDE.md34.7 KiB
- references/EVALUATION_METRICS.md55.9 KiB
- references/INFERENCE.md14.9 KiB
- references/SEARCH_METADATA.md7.7 KiB
- references/SWEEP.md10.6 KiB
- references/hardware.md4.8 KiB
- references/sweep_axes.md11.7 KiB
- scripts/preflight.shScript8.4 KiB
- scripts/write_manifest.pyScript9.6 KiB
- skill-card.md4.6 KiB
- skill.oms.sig9.9 KiB
references/INFERENCE.md
Inference and Search Guide
How to run protein design with Proteina-Complexa: local execution, SLURM cluster deployment, custom targets, and troubleshooting.
Documentation Map
Tuning YAML configs? See Configuration Guide.
Understanding metrics? See Evaluation Guide.
Parameter sweeps? See Sweep System.
Search metadata? See Search Metadata.
Table of Contents
Pipeline Overview
Design Pipeline Types
Configuration Architecture
Running Locally
SLURM Cluster Execution
Defining Custom Targets
Troubleshooting
Examples
Pipeline Overview
All design pipelines share the same four-stage structure:
| Stage | Module | Config Section | Description |
|---|---|---|---|
| 1. Generate | proteinfoundation.generate | generation.* | Sample structures using flow matching + reward scoring |
| 2. Filter | proteinfoundation.filter | generation.filter.* | Filter samples by reward scores |
| 3. Evaluate | proteinfoundation.evaluate | metric.* | Redesign sequences and validate with structure prediction |
| 4. Analyze | proteinfoundation.analyze | aggregation.* | Aggregate metrics, compute success rates, diversity |
Design Pipeline Types
There are three main design pipelines, each targeting a different design task:
Protein Binder Pipeline
Design protein binders for target proteins. Uses AF2 as the primary reward model and ColabDesign (AF2) or RF3 for evaluation refolding.
complexa design configs/search_binder_local_pipeline.yaml \
++run_name=my_binder ++generation.task_name=02_PDL1| Aspect | Setting |
|---|---|
| Model | Protein model (complexa.ckpt) |
| Generation reward | AF2 folding (TMOL, bioinformatics optional) |
| Inverse folding | SolubleMPNN |
| Evaluation folding | ColabDesign (default), RF3 |
| Evaluation type | protein_type: binder, result_type: protein_binder |
| Analysis modes | [binder, monomer] |
Ligand Binder Pipeline
Design proteins that bind small-molecule ligands. Uses RF3 for both reward and evaluation since it can handle protein-ligand complexes.
complexa design configs/search_ligand_binder_local_pipeline.yaml \
++run_name=my_ligand_binder ++generation.task_name=39_7V11_LIGAND| Aspect | Setting |
|---|---|
| Model | Ligand model with LoRA (complexa_ligand.ckpt) |
| Generation reward | RF3 folding |
| Inverse folding | LigandMPNN |
| Evaluation folding | RF3 |
| Evaluation type | protein_type: binder, result_type: ligand_binder |
| Analysis modes | [binder, monomer] |
AME Pipeline (Motif + Ligand Binder)
Scaffold functional motifs with ligand context. Combines motif features (atom-spec mode) and ligand features. Uses RF3 for reward and evaluation.
complexa design configs/search_ame_local_pipeline.yaml \
++run_name=my_ame ++generation.task_name=M0096_1chm| Aspect | Setting |
|---|---|
| Model | AME model with LoRA (complexa_ame.ckpt) |
| Generation reward | RF3 folding |
| Inverse folding | LigandMPNN |
| Evaluation folding | RF3 |
| Evaluation type | protein_type: motif_binder, result_type: motif_ligand_binder |
| Analysis modes | [motif_binder, binder, monomer] |
| Extra metrics | Motif RMSD, motif sequence recovery, ligand clash detection |
Motif Binder Evaluation (Standalone)
Each base binder type (protein, ligand) has a motif counterpart that adds motif preservation metrics on top of the standard binder evaluation. The AME pipeline automatically uses motif_ligand_binder, but you can also run motif binder evaluation standalone on outputs from any binder pipeline:
# Motif protein binder evaluation (on outputs from protein binder pipeline)
complexa evaluate configs/evaluate_motif_binder.yaml \
++dataset.task_name=MY_MOTIF_TASK \
++metric.binder_folding_method=colabdesign \
++metric.inverse_folding_model=soluble_mpnn
# Analysis (set result_type to match)
complexa analyze configs/analyze_motif_binder.yaml \
++result_type=motif_protein_binder| Variant | result_type | Binder thresholds | Motif thresholds |
|---|---|---|---|
| Motif Protein Binder | motif_protein_binder | i_pAE*31 <= 7.0, pLDDT >= 0.8, scRMSD_ca < 2.0 | motif_rmsd < 2.0, seq_recovery >= 1.0 |
| Motif Ligand Binder | motif_ligand_binder | scRMSD_bb3 <= 2.0 | motif_rmsd <= 1.5, seq_recovery >= 1.0, no ligand clashes |
Configuration Architecture
The pipeline uses a modular config system. Each top-level pipeline config composes stage-specific sub-configs via Hydra defaults:
configs/search_binder_local_pipeline.yaml
├── pipeline/binder/binder_generate.yaml → generation.*
├── pipeline/binder/binder_evaluate.yaml → metric.*
└── pipeline/binder/binder_analyze.yaml → aggregation.*
configs/search_ligand_binder_local_pipeline.yaml
├── pipeline/ligand_binder/ligand_binder_generate.yaml → generation.*
├── pipeline/ligand_binder/ligand_binder_evaluate.yaml → metric.*
└── pipeline/ligand_binder/ligand_binder_analyze.yaml → aggregation.*
configs/search_ame_local_pipeline.yaml
├── pipeline/ame/ame_generate.yaml → generation.*
├── pipeline/ame/ame_evaluate.yaml → metric.*
└── pipeline/ame/ame_analyze.yaml → aggregation.*For the full config structure, pipeline YAML examples, and every configurable parameter, see the Configuration Guide.
Note: You can also run individual modules directly with
python -m proteinfoundation.generate,python -m proteinfoundation.evaluate, etc. ThecomplexaCLI wraps these with additional validation and logging.
Running Locally
Quick Start
# Protein binder design
complexa design configs/search_binder_local_pipeline.yaml \
++run_name=my_binder ++generation.task_name=02_PDL1
# Ligand binder design
complexa design configs/search_ligand_binder_local_pipeline.yaml \
++run_name=my_ligand_binder ++generation.task_name=39_7V11_LIGAND
# AME motif scaffolding
complexa design configs/search_ame_local_pipeline.yaml \
++run_name=my_ame ++generation.task_name=M0096_1chmValidate Before Running
complexa validate design configs/search_binder_local_pipeline.yaml
complexa validate design configs/search_ligand_binder_local_pipeline.yaml
complexa validate design configs/search_ame_local_pipeline.yamlIndividual Stages
complexa generate configs/search_binder_local_pipeline.yaml
complexa filter configs/search_binder_local_pipeline.yaml
complexa evaluate configs/search_binder_local_pipeline.yaml
complexa analyze configs/search_binder_local_pipeline.yamlThe same stage commands work for all pipeline configs -- just substitute the config path.
CLI Options
# Verbose mode (show output instead of logging to file)
complexa design configs/search_binder_local_pipeline.yaml --verbose
# Override any config parameter with ++key=value
complexa design configs/search_binder_local_pipeline.yaml \
++generation.args.nsteps=200 \
++metric.binder_folding_method=rf3_latestCommon Overrides
# Change target
++generation.task_name=33_TrkA
# Change search algorithm
++generation.search.algorithm=beam-search
++generation.search.beam_search.beam_width=8
# Change sampling steps (fewer = faster, lower quality)
++generation.args.nsteps=200
# Change folding model for evaluation
++metric.binder_folding_method=rf3_latest
# Change reward weights (protein binder -- AF2)
++generation.reward_model.reward_models.af2folding.reward_weights.i_pae=-2.0
# Change reward weights (ligand binder / AME -- RF3)
++generation.reward_model.reward_models.rf3folding.reward_weights.min_ipAE=-2.0
# Change success thresholds for analysis
++aggregation.success_thresholds.i_pAE.threshold=5.0
# Change filter settings
++generation.filter.filter_samples_limit=500
++generation.filter.reward_threshold=0.5For the full list of configurable parameters, see the Configuration Guide.
Quick Local Test
complexa design configs/search_binder_local_pipeline.yaml \
++run_name=quick_test \
++generation.task_name=02_PDL1 \
++generation.args.nsteps=100 \
++generation.dataloader.dataset.nres.nsamples=2| Config | Use case |
|---|---|
search_binder_local_pipeline.yaml | Protein-protein binder design (local) |
search_ligand_binder_local_pipeline.yaml | Small-molecule binder design (local) |
search_ame_local_pipeline.yaml | AME motif scaffolding (local) |
search_binder_pipeline.yaml | Protein binder design (SLURM cluster) |
SLURM Cluster Execution
Setup
Create user configuration:
cp slurm_utils/.user_info_example slurm_utils/.user_infoEdit
.user_infowith your cluster credentials:
USER="your_username"
REMOTE="cluster.example.com"
ROOT_REMOTE="/path/to/workspace"
ENV_BINDER="complexa"
PYTHON_BINDER="/path/to/python"
MAMBA_EXEC="/path/to/mamba"Launch Scripts
From local machine (SSH to cluster):
# Single target
bash slurm_utils/launch_protein_binder_search_from_local_conda.sh 02_PDL1
# Single target with run number
bash slurm_utils/launch_protein_binder_search_from_local_conda.sh 02_PDL1 2
# All targets from config
bash slurm_utils/launch_protein_binder_search_from_local_conda.sh
# Multiple targets via loop
bash slurm_utils/launch_protein_binder_search_target_loop_conda.shDirectly on cluster:
./slurm_utils/launch_protein_binder_search_from_slurm_conda.sh 02_PDL1
./slurm_utils/launch_protein_binder_search_from_slurm_conda.sh # all targetsWhat the Launcher Does
Config generation -- Creates per-run configs in
configs/inference_configs/andconfigs/eval_configs/Code sync -- Rsyncs code to cluster (local launcher only)
Job submission -- Submits SLURM array jobs for each stage
Monitoring -- Waits for each stage to complete before proceeding
Result download -- Downloads results locally (local launcher only)
Job Parallelism
Use gen_njobs and eval_njobs to parallelize across samples:
complexa evaluate configs/search_binder_pipeline.yaml \
++eval_njobs=20 \
++job_id=$SLURM_ARRAY_TASK_IDSet eval_njobs to match gen_njobs so each eval job processes one generation job's outputs.
Defining Custom Targets
Protein Targets
Add entries to configs/targets/targets_dict.yaml:
target_dict_cfg:
my_target:
source: my_targets # Subfolder in $DATA_PATH/target_data/
target_filename: my_protein # PDB filename (without .pdb)
target_input: A1-150 # Chain and residue range
hotspot_residues: [A45, A67, A89]
binder_length: [60, 120] # [min, max] binder length
pdb_id: 1abc # Optional: PDB ID referenceThen run:
complexa design configs/search_binder_local_pipeline.yaml \
++generation.task_name=my_targetLigand Targets
Add entries to configs/targets/ligand_targets_dict.yaml with additional fields:
target_dict_cfg:
my_ligand_target:
source: my_targets
target_filename: my_complex
target_input: A1-200
binder_length: [60, 120]
pdb_id: 2xyz
res_name: LIG # Ligand residue name in PDB
ligand_only: false # Whether the target is ligand-only
SMILES: "CCO" # SMILES string for the ligand
use_bonds_from_file: true # Use bond topology from PDBTarget Input Format
The target_input field specifies which residues to use:
A1-150-- Chain A, residues 1-150A1-100,B1-50-- Multiple chains/rangesA-- Entire chain A
Hotspot Residues
Interface residues the binder should contact:
hotspot_residues: [A45, A67, A89, A102]Troubleshooting
Import Errors
Set PYTHONPATH if running without installation:
export PYTHONPATH=/path/to/project/src:/path/to/project/community_models:$PYTHONPATHMissing Model Weights
complexa download --statusConfig Validation Failures
complexa validate design configs/search_binder_local_pipeline.yaml --verboseRF3 Environment Variables
RF3 requires RF3_CKPT_PATH and RF3_EXEC_PATH to be set. Add them to your .env or export them:
export RF3_CKPT_PATH=/path/to/rf3_latest.pt
export RF3_EXEC_PATH=/path/to/rf3SLURM Job Failures
ls slurm_run_outputs/inf/ # Generation logs
ls slurm_run_outputs/eval/ # Evaluation logsMemory Issues
Reduce batch size or parallelization:
++generation.dataloader.batch_size=8
++gen_njobs=1
++eval_njobs=1Examples
Production Beam Search (Protein Binder)
complexa design configs/search_binder_local_pipeline.yaml \
++run_name=pdl1_beam_v1 \
++generation.task_name=02_PDL1 \
++generation.search.algorithm=beam-search \
++generation.search.beam_search.beam_width=8 \
++generation.search.beam_search.n_branch=4Multiple Targets on SLURM
# Launch all targets defined in config
bash slurm_utils/launch_protein_binder_search_target_loop_conda.sh
# Or specific targets
for target in 02_PDL1 33_TrkA 24_SpCas9; do
bash slurm_utils/launch_protein_binder_search_from_local_conda.sh $target
doneHigh-Quality Protein Binder Campaign
complexa design configs/search_binder_local_pipeline.yaml \
++run_name=high_quality_campaign \
++generation.search.algorithm=beam-search \
++generation.search.beam_search.beam_width=8 \
++metric.binder_folding_method=rf3_latest \
++metric.num_redesign_seqs=16To also enable TMOL rewards during generation, uncomment the tmol sub-model in binder_generate.yaml or add it via CLI:
++generation.reward_model.reward_models.tmol._target_=proteinfoundation.rewards.tmol_reward.TmolRewardModel \
++generation.reward_model.reward_models.tmol.enable_hbond=true \
++generation.reward_model.weights.tmol=0.5Custom Success Criteria
# Protein binder with stricter thresholds
complexa analyze configs/search_binder_local_pipeline.yaml \
++aggregation.success_thresholds.i_pAE.threshold=5.0 \
++aggregation.success_thresholds.scRMSD.threshold=1.0
# AME motif binder with custom thresholds
complexa analyze configs/search_ame_local_pipeline.yaml \
++aggregation.motif_binder_success_thresholds.motif_rmsd_pred.threshold=1.0 \
++aggregation.motif_binder_success_thresholds.motif_seq_recovery.threshold=0.8Custom Filter Settings
complexa filter configs/search_binder_local_pipeline.yaml \
++generation.filter.filter_samples_limit=200 \
++generation.filter.reward_threshold=0.3Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Declares allowed tools, Needs Python
Security
What our scanner noticed· Medium risk
- Large base64-encoded blobs
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Ohad Mosafi
- Publisher
- NVIDIA (Official)
- Distributed by
- NVIDIA
- Source
- NVIDIA/skills · skills/bionemo-complexa-sweep · commit fce3cca
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE-APACHE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Ohad Mosafi or NVIDIA.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download complexa-sweep.zip