codonfm-setup

Files (9)

• BENCHMARK.md
• SKILL.md
• openai.yaml · agents/
• config.yml · evals/
• evals.json · evals/
• codonfm_source.zip · evals/files/
• encodon_checkpoint.json · evals/files/
• skill-card.md
• skill.oms.sig

SKILL.md (first lines)

# CodonFM public setup

Operate from the public CodonFM repository root. Support only the checked-in
public v1 code and public Encodon checkpoints.

## Instructions

1. Determine whether the user wants instructions, a downloaded checkpoint, a
   working model environment, or a combination of these.
2. For setup instructions or runtime work, inspect the supplied files and
   configuration directly: the [runner](../../src/runner.py),
   [model configuration](../../src/config.py), [Dockerfile](../../Dockerfile),
   [launcher](../../run_dev.sh), and [requirements](../../requirements.txt).
   Runtime setup requires a checkout; a supplied source archive is sufficient
   for preparing instructions.
3. Check the [public-v1 boundaries](#public-v1-boundaries). For an unsupported
   request, inspect `MODEL_ARCHITECTURES` in `src/config.py`, the model modules,
   and any requested script before explaining the boundary and ending that
   path. Runner argument choices alone do not establish implementation support.
4. Reuse available environments and checkpoints, and choose explicit paths
   from the user's project.
5. Follow only the requested paths below. Environment setup alone does not
   require a checkpoint download; download weights only when the request needs
   them and a suitable local checkpoint is unavailable.

| Requested scope | Action and completion condition |
| --- | --- |
| Instructions only | Inspect the supplied source/configuration, provide the commands described under Reporting setup instructions, then stop. No installation or GPU verification is required. |
| Checkpoint only | Follow Download a checkpoint, check the downloaded files, report their paths, then stop. No Docker, GPU, or model runtime is required. |
| Working model environment | Follow Runtime preflight, choose the container or direct-host path, then Verify the runtime. Report the checks performed and any remaining limitations. |

For supplied source archives, inspect selected files with the available Python
3 standard library (`zipfile.ZipFile.namelist()` and `read()`) without extracting
the whole archive. If extraction is needed, use a fresh directory from
`mktemp -d` or `tempfile.mkdtemp()`. Preserve existing checkouts and temporary
directories; do not delete or overwrite them to prepare a source inspection.

The runner's optional `--dryrun` requires the ML dependencies to be installed
already. It constructs runtime configuration, then stops before execution.
It does not install packages, validate CSV data, or load weights. Preparing
setup instructions does not require running it.

## Reporting setup instructions

For instruction requests, put complete commands for the requested setup path
early in a compact, self-contained answer, even when also writing a guide file.

- For downloads, use supplied checkpoint metadata for the exact repository,
  revision, weight filename, and `config.json`. Show the destination directory
  and keep the weights and configuration together.
- For containers, state Docker/GPU prerequisites, explain existing-container
  replacement before the launcher command, and show explicit host data and
  checkpoint paths and the checkpoint mount at `/data/checkpoints`.
- For direct-host setup, include `python3.11 -m venv`,
  `python -m pip install -r requirements.txt`, a writable `MPLCONFIGDIR`,
  `torch.cuda.is_available()` verification, and explicit host checkpoint paths.
- State which checks actually ran and what remains unverified before model
  execution. Written instructions alone do not establish a working environment.

For a compatibility-only question, give the source-backed availability answer
without adding an unrelated installation procedure.

## Runtime preflight

For a working environment, check hardware before installing the runtime: use
`nvidia-smi` if available, or check CUDA through an existing PyTorch installation.
Actual model execution requires the ML dependencies and a compatible NVIDIA GPU.
Compare the driver with the CUDA version required by the selected runtime using
[NVIDIA's compatibility guidance](https://docs.nvidia.com/deploy/cuda-compatibility/minor-version-compatibility.html).
For the Dockerfile's `nvcr.io/nvidia/pytorch:24.10-py3` base, also check the
[24.10 driver requirements](https://docs.nvidia.com/deeplearning/frameworks/pytorch-release-notes/rel-24-10.html#driver-requirements).
If a prerequisite is missing, follow Failure handling below.

### Container preflight

1. Confirm `Dockerfile`, `run_dev.sh`, and `src/runner.py` exist.
2. Confirm `docker info` succeeds. Docker must have NVIDIA Container Toolkit
   configured for `--gpus all`; host GPU visibility alone does not establish
   container GPU access. Verify access in the launched container below.
3. Run `bash -n run_dev.sh` before launching it.
4. Resolve existing absolute host paths for data and checkpoints. Always pass
   both path flags to the launcher rather than relying on `/data/codonfm`
   defaults. Create missing project directories only as needed for the request.
5. Check for an existing container before launch:

```bash
docker ps -a --filter name='^/codon-fm-dev-container$'
```

If an exact-name container is running, `run_dev.sh` stops and removes it; tell
the user before replacement. If it is stopped, the script cannot reuse the
name, so obtain confirmation before removing it with
`docker rm codon-fm-dev-container`. If removal is declined, preserve the
container, skip this launch, and report the name conflict.

The public script uses host networking/IPC and mounts the user's SSH directory
read-only; disclose this before execution. It has no opt-out flags for these
settings. If they conflict with the user's constraints, use the direct-host
path when feasible; otherwise report that container launch remains blocked.

## Build and launch

Set `CODONFM_REPO_DIR`, `CODONFM_DATA_DIR`, and `CODONFM_CHECKPOINT_DIR` to
existing absolute paths chosen for the project.

```bash
cd "${CODONFM_REPO_DIR:?Set the repository path}"
bash run_dev.sh \
    --data-dir "${CODONFM_DATA_DIR:?Set the host data path}" \
    --checkpoints-dir "${CODONFM_CHECKPOINT_DIR:?Set the host checkpoint path}"
```

The host checkpoint directory is mounted at `/data/checkpoints` inside the
container. The image is `codon-fm-dev`; the container is
`codon-fm-dev-container`.

Use only the checked-in public code and the dependency versions declared in
its `Dockerfile` and `requirements.txt`. Continue to Verify the runtime after
launch; checkpoint downloads are a separate requested action.

From NVIDIA/skills, Apache-2.0.

More from NVIDIA/skills