Generated banner for Complexa Sweep
Generated logo for Complexa Sweep

Complexa Sweep

NVIDIAOfficialCreated by Ohad MosafiDistributed by NVIDIA

  • Skill
  • Workflow
  • Science and research
  • Apache-2.0
  • Medium risk
  • Has scripts

From the author

Agent runbook for Proteina-Complexa parameter sweeps through the separately installed first-party CLI and config generator. Use for cartesian-product hyperparameter scans, sweeper YAML authoring, configuration comparisons, ablations, tuning, success-rate ranking, or Pareto searches over quality and wall-clock cost. Do not use for a single existing-job launch or SLURM submission template. SKILL.md performs the orchestration; bundled executables only inspect local readiness and write a run manifest.
— the description by Ohad Mosafi

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/complexa-sweep/download
  2. Unzip 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 design CLI does NOT accept --sweeper directly. Sweeps are driven by script_utils/generate_inference_configs.py, which writes one configs/inference_configs/inf_{idx}_{run_name}.yaml per sweep combination. You then loop complexa design over 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.sh

Read ./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
FileAxisValuesConfigs
configs/sweeps/beam_width.yamlgeneration.search.beam_search.beam_width1, 2, 4, 84
configs/sweeps/bb_ca_temperature.yamlgeneration.model.bb_ca.simulation_step_params.sc_scale_noise0.1, 0.42
configs/sweeps/search_replicas.yamlgeneration.search.best_of_n.replicas1, 4, 16, 644
configs/sweeps/example.yamlbeam_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
  - 400

Rules (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 targets list 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; --override parses 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 \
    --dryrun

The 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"
done

This 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
wait

Drop 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_*.csv

Inspect 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:

ColumnHow to compute
config_idThe {idx} from inf_{idx}_{run_name}
<axis_1>, <axis_2>, ...The swept value at this combination (read from the per-config inf_*.yaml)
n_samplesn_designs for a supplied config summary, otherwise per-design row count
success_raten_passed / n_designs for a config summary, otherwise mean of parsed per-design pass flags
mean_i_paePreserve the supplied config mean, or average per-design values in consistent units (lower = better)
mean_i_plddti_plddt.mean() (higher = better)
diversity_scoreUnique sequence count / n_samples (or use TM-score clustering if available)
wall_clock_minFrom 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 on mean_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.json

Alongside 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.

SymptomSweep thisWhy
Quality not good enoughbeam_width × nsteps (use example.yaml as a starting point)Both raise compute → quality; find the cheapest combination that lands.
Too slow / want speed-upnsteps downward (e.g. [100, 200, 400]) with fixed beam_width=4Find the smallest nsteps that retains success rate.
Mode collapse / low diversitygeneration.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} ratioRe-balance composite reward.
Broaden the best-of-N candidate poolsearch_replicas.yaml (best_of_n.replicas)More candidates per search; use separate seeds/runs to measure repeatability.
Algorithm shoot-outgeneration.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

SymptomCauseFix
Sweeper file not found from generate_inference_configs.pyPath resolved from wrong CWDUse a path relative to the repo root; or pass an absolute path.
Sweeper YAML must be a mappingTop-level YAML is a list or scalarRewrite as key: [v1, v2] mapping.
Dry-run reports zero config pairsOne 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 --sweeperConfusion between entrypointsThe 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 keyDrop either the override OR the matching key from the sweeper file.
One config in the loop fails, sweep keeps goingThe || echo "FAILED…" in Step 4 swallows the errorRe-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

references/SWEEP.md

Sweep System

How to run parameter sweeps and override experiment settings without modifying source code.

Documentation Map

Overview

The sweep system has two mechanisms that work together:

  • --sweeper FILE loads a YAML file defining one or more parameter axes. All combinations are generated as a cartesian product.

  • --override KEY=VAL [KEY=VAL ...] pins individual parameters to scalar values, applied to every generated config.

Both can be used independently or combined. When a key appears in both the sweeper file and the CLI overrides, the override wins and that axis is collapsed to a single value.

Quick Start

# 1. Single experiment with a specific target (no sweep)
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
    --override generation.task_name=22_DerF21

# 2. Sweep beam widths for a single target
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
    --sweeper configs/sweeps/beam_width.yaml \
    --override generation.task_name=22_DerF21

# 3. Sweep beam widths with nsteps pinned to 400
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
    --sweeper configs/sweeps/beam_width.yaml \
    --override generation.task_name=22_DerF21 generation.args.nsteps=400

# 4. Dry run to preview config generation
python script_utils/generate_inference_configs.py \
    --config_name search_binder_pipeline \
    --sweeper configs/sweeps/beam_width.yaml \
    --override generation.task_name=22_DerF21 \
    --dryrun

Sweep YAML Format

Sweep files live in configs/sweeps/. Each key is a dot-notation config path and each value is a list of values to sweep over:

# configs/sweeps/beam_width.yaml
generation.search.beam_search.beam_width:
  - 1
  - 2
  - 4
  - 8

Multiple axes produce a cartesian product:

# 3 beam widths x 2 nsteps = 6 configs
generation.search.beam_search.beam_width:
  - 2
  - 4
  - 8

generation.args.nsteps:
  - 200
  - 400

Long values (e.g., checkpoint paths) benefit from YAML block-list style:

ckpt_path:
  - /path/to/checkpoints/model_v1/epoch_100.ckpt
  - /path/to/checkpoints/model_v2/epoch_200.ckpt
  - /path/to/checkpoints/model_v3/epoch_50.ckpt

A scalar value (not a list) is automatically wrapped in a single-element list, so it pins that parameter without adding a sweep dimension:

generation.args.self_cond: true

--override Format

Override arguments are KEY=VALUE strings where:

  • The key uses dot notation (e.g., generation.args.nsteps)

  • The value is auto-typed: integers, floats, booleans (true/false), null (null/none), or strings

--override generation.task_name=22_DerF21 generation.args.nsteps=400 generation.args.self_cond=true

Multiple overrides are space-separated after a single --override flag.

How It Works

Config Generation Pipeline
                    +-----------------+
                    | Sweeper YAML    |  (optional)
                    +-----------------+
                            |
                            v
+-----------+      +------------------+      +-------------------+
| Pipeline  | ---> | generate_infer-  | ---> | N inf_*.yaml +    |
| Config    |      | ence_configs.py  |      | N eval_*.yaml     |
+-----------+      +------------------+      +-------------------+
                            ^
                            |
                    +-----------------+
                    | --override      |  (optional)
                    | KEY=VAL ...     |
                    +-----------------+
  1. The base pipeline config (e.g., search_binder_pipeline.yaml) is loaded via Hydra.

  2. If a --sweeper file is provided, its axes are combined into a cartesian product.

  3. For each combination, the sweep values are merged into the base config.

  4. --override values are applied on top of every config (overriding sweep values if they conflict).

  5. Each config gets a unique root_path and is saved as a pair: inf_{idx}_{run}.yaml and eval_{idx}_{run}.yaml.

Config Naming

Generated config filenames follow the pattern:

inf_{index}_{run_name}.yaml
eval_{index}_{run_name}.yaml

The index is sequential (0, 1, 2, ...) and the run name comes from the --run_name argument. Task name is intentionally NOT in the filename -- it lives inside the config content. This keeps filenames predictable so the bash launcher can construct Hydra --config-name paths without parsing YAML.

Directory Structure

On the remote cluster (and on-cluster direct launches), configs always live at the canonical paths:

configs/
  inference_configs/
    inf_0_my_run.yaml
    inf_1_my_run.yaml
  eval_configs/
    eval_0_my_run.yaml
    eval_1_my_run.yaml
Local-to-remote flow (with rsync)

When launching from a local machine, configs are first generated into a unique temporary directory (configs/_gen_XXXXXX/) so that concurrent launches never collide. Inside the rsync lock, the temp directory contents are staged (moved) into the canonical configs/inference_configs/ and configs/eval_configs/ paths, rsync'd to the cluster, and then cleaned up locally.

generate_configs()        →  configs/_gen_abc123/{inference_configs,eval_configs}/
stage_configs_for_sync()  →  configs/{inference_configs,eval_configs}/   (inside lock)
rsync                     →  $RUN_DIR/configs/{inference_configs,eval_configs}/
cleanup_staged_configs()  →  local canonical dirs removed                (inside lock)
Direct on-cluster flow (no rsync)

When running directly on the cluster, no temp directory is needed. Configs are generated straight into the canonical paths and used in-place by the SLURM array jobs.

Integration with SLURM Scripts

All three launcher scripts accept --sweeper and --override:

./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
    --sweeper configs/sweeps/beam_width.yaml \
    --override generation.task_name=22_DerF21

The on-cluster script works identically (no rsync needed):

./slurm_utils/launch_protein_binder_search_conda.sh \
    --sweeper configs/sweeps/beam_width.yaml \
    --override generation.task_name=22_DerF21

The multi-target loop wrapper also passes these through:

./slurm_utils/launch_protein_binder_search_target_loop_conda.sh \
    --sweeper configs/sweeps/beam_width.yaml \
    ./my_targets.txt
Legacy Positional Arguments

The TARGET_TASK positional argument is still supported for backward compatibility. Internally it is converted to --override generation.task_name=$TARGET_TASK.

Running Concurrent Experiments

The system is designed for safe concurrent launches:

  • Local config isolation: Each launch generates configs in a unique mktemp -d configs/_gen_XXXXXX directory. Before rsync (inside the lock), configs are staged to the canonical configs/inference_configs/ and configs/eval_configs/ paths, rsync'd, then cleaned up. This means the generation phase is fully parallel, and the staging+rsync phase is serialised by the lock.

  • Remote directory uniqueness: The run name on the cluster includes the sweeper file basename (e.g., my_run-search-beam_width-22_DerF21), making collisions nearly impossible for different sweeps.

  • Lock file for rsync: The .lock file prevents simultaneous rsync operations from corrupting the code copy.

Example: launching two experiments in parallel from different terminals:

# Terminal 1: sweep beam widths for target A
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
    --sweeper configs/sweeps/beam_width.yaml \
    --override generation.task_name=22_DerF21

# Terminal 2: sweep replicas for target B (safe to run simultaneously)
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
    --sweeper configs/sweeps/search_replicas.yaml \
    --override generation.task_name=02_PDL1

Running Individual Pipeline Stages

The core Python modules (generate, filter, evaluate, analyze) can still be run independently with Hydra ++key=value overrides:

# Run just evaluation on existing inference outputs
python -m proteinfoundation.evaluate \
    --config-path /path/to/eval_configs \
    --config-name eval_0_22_DerF21_my_run \
    ++eval_njobs=4

The sweep system only affects config generation and the bash pipeline orchestration. It does not change how individual modules consume configs.

Migration from Old System

OldNew
Edit sweeper = {...} dict in PythonCreate a YAML file in configs/sweeps/
--target_task_override 22_DerF21--override generation.task_name=22_DerF21
--unified flagRemoved (always unified pipeline mode)
--eval_config_name evaluateRemoved (eval derived from pipeline config)
--infer_config_name search_binder--config_name search_binder_pipeline
generate_binder_inference_configs.pygenerate_inference_configs.py
Hardcoded ALPHA_PROTEO_TARGETS listRemoved (use sweep or override)
Manually delete generated configuration filesAutomatic: temp dir + staging (concurrent-safe)

Tests

The sweep system is covered by tests/test_sweep.py (92 tests):

pytest tests/test_sweep.py -v

Test categories:

  • TestParseScalar / TestParseOverride: Value parsing and type inference

  • TestLoadSweeperFile: YAML loading and validation

  • TestBuildSweeper: Merge logic and conflict resolution

  • TestDotKeyDictToNestedDict: Dot-notation conversion

  • TestGetTaskNameFromConfig / TestCreateEvalConfig: Config helpers

  • TestApplySweeperAndSaveConfigs: End-to-end cartesian product, value propagation, unique paths, filename conventions

  • TestConcurrentSafety: Parallel generation without collisions

  • TestBuildParser: CLI argument parser validation

  • TestCreateEvalConfigNjobs: eval_njobs priority regression tests

  • TestCreateEvalConfigPaths: Path derivation edge cases

  • TestEmptySweepAxis: Zero-config guard regression tests

  • TestConfigFilenameContract: Filename contract between Python and bash

  • TestEvalPathEdgeCases: Eval path derivation with adversarial inputs

Requirements 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