You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- New `conf/base.config` (always loaded): a universal per-process resource floor (`cpus=1`, `memory=2.GB*attempt`) so every module has a baseline, plus a correctness fix pinning the chunk producers (`chunk_ids_by_zip`/`light_chunk_consensus_by_zip`) to `scratch=false` — node-local scratch was deleting their mapping-file outputs and breaking `filter_pdb_from_zip`/`chop_pdb_from_zip`.
7
+
- Per-process HPC resource ladders / retries remain in `conf/singularity.config` (HPC runs use singularity).
8
+
- Profiles are now composable: added a standalone `container` profile; `cs_cluster` is generic + label-aware (requests `gpu=true` for `sge_gpu_high`, `avx2=yes` for foldseek) and runs on shared `/SAN` (`scratch=false`); `orengo` restored as a composable profile for backward compatibility. Compose e.g. `-profile <data>,singularity,cs_cluster`.
9
+
-`cs_cluster` Singularity image cache now honours `NXF_SINGULARITY_CACHEDIR` (falls back to `$HOME/.apptainer/pull`); removed the unused `singularity_image_dir` param.
10
+
- Added `test_154` profile: 154-id TED test set read from a public S3 bucket `s3://excon/protein-domain-annotation/zip/` using anonymous access (`aws.client.anonymous`) — no AWS login needed.
- Split `run_ted_segmentation` into three modules so Chainsaw runs concurrently with the Merizo→UniDoc chain (Chainsaw is independent; UniDoc inherits Merizo's chopping). New modules: `run_ted_merizo_unidoc` and `run_ted_chainsaw` (both GPU), and `run_ted_consensus` (CPU, `sge_low`) which joins the three choppings by `chunk_id` and computes consensus.
14
+
- Cuts this step's wall time to roughly `max(merizo+unidoc, chainsaw) + consensus`, at the cost of two GPU slots per chunk. Pipeline outputs are unchanged; the original `modules/run_ted_segmentation.nf` is retained but no longer used.
15
+
16
+
## 2026-06-22 (Chris Wyatt)
17
+
- Updated for Nextflow 25.10+/26 (see README). Fixed `--chunk_size` which broke under v26 (now coerced to an integer before validation).
18
+
- Execution reports (timeline, report, trace, DAG) are now generated automatically into a timestamped `reports/` folder — no need to pass `-with-timeline`/`-with-report`/`-with-trace`.
19
+
5
20
## 2025-10-31 (Nick Edmunds)
6
21
- Added this changelog to track key updates.
7
22
- To run on the server must include a link to: -c /SAN/orengolab/bfvd/code/domain-annotation-pipeline/nextflow.config
Copy file name to clipboardExpand all lines: README.md
+74-3Lines changed: 74 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,8 @@ pip install --upgrade pip
16
16
pip install nextflow
17
17
```
18
18
19
+
**Nextflow version:** use **25.10 or newer** (tested with 25.10.3 and 26.04.4). These releases use Nextflow's strict (v2) config parser, which `nextflow.config` is written for. If `pip install nextflow` gives you an older release, set the version explicitly, e.g. `NXF_VER=26.04.4 nextflow run ...`.
20
+
19
21
Install Docker
20
22
https://docs.docker.com/compose/install/
21
23
@@ -34,6 +36,46 @@ Note: either docker or singularity must be supplied as one the the profile argum
34
36
nextflow run workflows/annotate.nf -profile debug,docker
35
37
```
36
38
39
+
### Profiles
40
+
41
+
Runs are configured by composing profiles with `-profile a,b,c`: pick **one container engine**, add a **cluster** profile on HPC, and a **data/mode** profile for the inputs.
42
+
43
+
| Group | Profiles | Sets |
44
+
|-------|----------|------|
45
+
| Container engine *(pick one)*|`docker`, `singularity`| how containers run (also loads the `/app` script paths) |
| Data / mode |`debug`, `benchmark_test`, `stub_run`, `test_154`, … | test inputs / run parameters |
48
+
49
+
A basic resource floor for every process lives in `conf/base.config` (always applied). The fuller per-process memory/retry ladders are HPC settings in `conf/singularity.config`, so they apply when you include the `singularity` profile — hence `-profile singularity,<cluster>` for real HPC jobs. (`container` is also available as a standalone profile: script paths only, for composing with a self-contained cluster profile such as `orengo`.)
50
+
51
+
```bash
52
+
# Local, Docker, bundled test data
53
+
nextflow run workflows/annotate.nf -profile debug,docker
54
+
55
+
# UCL CS cluster — Singularity, runs on shared /SAN (no node-local scratch)
56
+
nextflow run workflows/annotate.nf -profile singularity,cs_cluster --input_zip_dir <dir>
57
+
58
+
# UCL Myriad cluster
59
+
nextflow run workflows/annotate.nf -profile singularity,myriad_cluster --input_zip_dir <dir>
nextflow run workflows/annotate.nf -profile singularity,orengo --input_zip_dir <dir>
63
+
64
+
# 154-id TED test set read from a public S3 bucket (no AWS login needed)
65
+
nextflow run workflows/annotate.nf -profile test_154,singularity,cs_cluster
66
+
```
67
+
68
+
### Execution reports
69
+
70
+
Execution timeline, report, trace and DAG files are generated **automatically** on every run — you do **not** need to pass `-with-timeline`, `-with-report`, `-with-trace` or `-with-dag`. They are written to the `reports/` folder (or under `--results_dir` if you set it) and the filenames include a per-launch timestamp, so successive runs never overwrite each other:
71
+
72
+
```
73
+
reports/execution_timeline_<timestamp>.html
74
+
reports/execution_report_<timestamp>.html
75
+
reports/execution_trace_<timestamp>.txt
76
+
reports/pipeline_dag_<timestamp>.html
77
+
```
78
+
37
79
## Preparing data
38
80
39
81
The pipeline expects two inputs:
@@ -152,6 +194,34 @@ ted_stub_chain_ids.zip
152
194
153
195
The default files are currently set up to run a test set of 50 chain ids, producing a final results output of 100 domains.
154
196
197
+
## Automated tests (nf-test)
198
+
199
+
The pipeline has an [nf-test](https://www.nf-test.com/) (`tests/`) that runs the full `annotate.nf` workflow against the test data located in `./assets/test_ids` and checks the results against a pre-generated snapshot.
200
+
201
+
Install nf-test:
202
+
203
+
```bash
204
+
curl -fsSL https://get.nf-test.com | bash
205
+
```
206
+
207
+
Move `nf-test` to the `bin` folder in you `$PATH`.
208
+
209
+
Run the test locally:
210
+
211
+
```bash
212
+
nf-test test --profile +docker
213
+
```
214
+
215
+
If the outputs are consistent with the pre-existing snapshot, the test will succeed.
216
+
217
+
If a change intentionally alters pipeline outputs, generate a new snapshot with:
218
+
219
+
```bash
220
+
nf-test test --update-snapshot
221
+
```
222
+
223
+
Note: nf-test isn't wired into CI yet — `test-pipeline.yml` and `build-test-push.yml` run the pipeline directly with `-profile docker,git_actions_test` rather than through nf-test. The idea is to replace it the nf-test at some point.
The directory containing these singularity images can be added to your config file, or passed directly to nextflow:
282
+
You normally **don't** need to pull these manually — with `-profile singularity`, Nextflow pulls each image into its cache on first run. Control **where** they're stored (and share them across runs and users) with the `NXF_SINGULARITY_CACHEDIR` environment variable:
213
283
214
284
```bash
215
-
nextflow run workflows/annotate -profile singularity \
The `cs_cluster` profile (see below) honours this variable, falling back to `$HOME/.apptainer/pull` when it is unset. (The old `--singularity_image_dir` flag is no longer wired up — set the cache via the environment variable instead.)
0 commit comments