Training plan for spectrum transformers and fingerprint MLPs across Explorer (H200), Modal, Colab and Kaggle: memory, tokenisation, throughput, enveda-180 ablation, Slurm practicalities

TL;DR. train.parquet is 3.03 GB on disk but only 6.45 GB in pyarrow (401.8 M peaks, mean 158 / median 42 peaks per spectrum, measured here, not assumed), and a flattened float32/float16 offset layout clipped to the top-100 peaks is 0.80 GB — small enough to live on any GPU. A 25 M-parameter peak-token transformer (DreaMS/MassSpecGym style, 61 tokens per spectrum) costs about 2.7×10^16 FLOPs per epoch: ~2 min on one H200, ~6 min on a Modal A100 (about $10 for 50 epochs), ~15 min on a Colab L4, ~35 min on one Kaggle T4; a 36 M-parameter binned-fingerprint MLP is I/O-bound at 10–60 s per epoch anywhere. No public write-up ablates enveda-180; the only public data point (a model trained on enveda-180 alone scoring 0.138 vs 0.107 random on natural products) and our own finding that enveda-180 supplies 1,153,785 of the 1,154,969 timsTOF spectra in train together say: do not drop it, re-weight it and separate its instrument signal from its chemistry signal — the ablation grid below (R0–R6) is written as exact runs.

1. Memory and I/O — measured on the real file

All numbers below were computed on C:\Temp\casmi26\data\train.parquet (3,033,286,496 bytes, downloaded 2026-10-07 via the Kaggle CLI) with pyarrow 25.0.1; the script and raw JSON are in the worker scratchpad.

File facts. 2,539,608 rows, 21 row groups of 131,072 rows, ZSTD. ms2_mzs and ms2_normalized_intensities are list<double>; they are 98 % of the file: m/z 1.20 GB compressed / 3.21 GB raw, intensities 1.78 GB compressed / 3.13 GB raw (intensities compress worse because m/z values carry only 4 decimals — median and max decimals = 4 in a 20,000-peak sample — while intensities are full double precision). All metadata columns together are < 60 MB; reading them takes 0.3 s.

Peak statistics (whole file, num_peaks column, verified equal to len(ms2_mzs) on 1,048,576 sampled rows).

Per-library mean/median peaks: enveda-180 246.5/138 (1,153,785 spectra), enveda-np-examples 256.6/141.5 (1,184), gnps 218.5/46 (220,849), mona 293.6/57 (92,416), pluskal_ms2 35.1/21 (527,581), riken 36.7/9 (347,171), massbank 26.0/11 (101,727), msdial 43.0/11, spectraverse 113.6/47, drug_plus 112.3/108, masaryk 11.1/9. The timsTOF sources are the peak-rich ones (they are merged multi-CE spectra with a long noise tail: two-thirds of all peaks are below 0.1 % of base peak), so a top-k truncation throws away almost no information but ~67 % of the bytes. For comparison, published libraries cap much lower: MassSpecGym discards spectra with > 300 peaks after noise removal (arXiv 2410.23326, App. 2.3) and DreaMS keeps n = 60 peaks for pretraining, 100 for fine-tuning (Bushuiev et al., Nat Biotechnol 2025, Methods).

In-RAM size formulas (S = 2,539,608 spectra, N = 401,806,233 peaks).

The flattened layout is the one to train from: mz.npy (float32), inten.npy (float16, store sqrt- or log-intensity so float16 keeps dynamic range — 66 % of raw values are < 1e-3), offsets.npy (int64, S+1), plus meta.parquet. A 4-decimal m/z in float32 is exact to ±0.00003 Da below 1,000 Da (24-bit mantissa), fine for 0.01 Da bins; do not use float16 for m/z (3 significant digits).

Pre-binned dense tensors over m/z 50–1000 (float16; uint8 log-quantised halves it):

Consequence: 1 Da dense fits any GPU; 0.1 Da dense fits the 128 GB RAM request on Explorer (and the 135 GB local box) as a memmap but is 48 GB of traffic per epoch; 0.01 Da must be sparse — and a sparse 0.01 Da representation (int32 bin + float16 value = 6 B/nonzero ≤ 2.4 GB) is just the peak list again. The fastest epoch for an MLP is therefore: keep the 0.8 GB top-100 peak list on the GPU and scatter_reduce (amax) into the bin vector per batch; nothing is read from disk after startup. For a peak-token transformer, pad per batch to the batch max (bucket by num_peaks so padding waste is < 10 %). WebDataset shards or LMDB only pay off when the dataset does not fit in RAM; here it does on every target except Kaggle (16 GB system RAM, where the 0.8 GB file still fits).

2. Tokenisation: what the published models actually do

Three facts matter for us. (i) The Fourier m/z embedding is worth ~7× in hit@1 on an otherwise identical set model (0.37 → 2.54 %) — raw-float m/z is the single most expensive mistake a peak-token model can make. (ii) Every peak-token model caps peaks at 60–100; our data says the cap costs < 1 % of intensity mass. (iii) MIST's formula-labelled tokens beat raw peak tokens (5.24 vs 2.54 hit@1) but need a per-spectrum subformula decomposition (SIRIUS or MIST's internal labeller) — on 2.5 M spectra that pre-processing, not the GPU, is the budget item; the MassSpecGym team called MIST training "computationally costly" and ran only 5 hyperparameter combinations.

3. Throughput, wall-clock and dollars

Assumptions (all stated so the arithmetic can be checked).

• Transformer-S: 25 M params (d = 512, 8 layers, FFN 2,048, 6,000→512 Fourier projection, 4,096-bit fingerprint head), T = 61 tokens (top-60 + precursor). Train FLOPs/spectrum ≈ 6·P·T + 6·6000·512·T + 12·L·T²·d = 9.15e9 + 1.12e9 + 0.18e9 ≈ 1.05e10; epoch = 2.54e6 × 1.05e10 = 2.66e16 FLOPs.
• Transformer-L: 50 M params, T = 101 → ≈ 3.3e10/spectrum, 8.4e16 FLOPs/epoch.
• Fingerprint MLP: 9,500 (0.1 Da) → 2,048 → 2,048 → 2,048 → 4,096 = 36.3 M params → 6·P = 2.2e8 FLOPs/spectrum, 5.5e14/epoch; I/O-bound, not compute-bound.
• Dense tensor-core peaks used: H200 SXM 989 TFLOPS BF16 (NVIDIA quotes 1,979 "with sparsity"; Wikipedia Hopper table), A100 312 TFLOPS BF16 (Wikipedia Ampere table), L4 ≈ 121 TFLOPS FP16 (derived: NVIDIA L4 page states FP8 485 TFLOPS with sparsity and "half without sparsity"; FP16 is half of FP8 on Ada — the 121 figure itself is not on the page I opened), T4 65 TFLOPS FP16 (nvidia.com T4 page; no BF16 → fp16 AMP + loss scaling).
• MFU: 25 % for transformers (short sequences, small d — expect 20–35 %; measure it with a 200-step benchmark before trusting any row), 20 % on T4, 15 % for the MLP. DDP scaling efficiency 0.85 (4× H200), 0.8 (2× T4).
• Prices from modal.com/pricing (per-second, fetched 2026-10-07): H200 $0.001261/s = $4.54/h; H100 $3.95/h; A100-80 GB $2.50/h; A100-40 GB $0.000583/s = $2.10/h; L40S $1.95/h; L4 $0.80/h; T4 $0.59/h; B200 $6.25/h; CPU $0.0472/core-h; RAM $0.008/GiB-h; $30/month free on Starter. Note the brief's "~$1.4/GPU-h" is below any current Modal GPU price — treat it as stale.

Memory check for Transformer-S at batch 1,024: activations ≈ 1,024 × 61 × 512 × 8 layers × ~34 B/element ≈ 8.7 GB — fits a 16 GB T4 at batch 512 and an L4 at 1,024; H200 can take 8,192 with no loss of MFU (use a LR warm-up and sqrt scaling).

How to split the work.

1. Explorer gyorilab (one node, 4× H200, 96 cores, 773 GB RAM, default 7 d, max 30 d, PriorityTier 10, group-restricted) is where every transformer run and the whole ablation grid of §4 goes: the full grid (7 runs × 50 epochs of Transformer-S) is ~10 h on one H200, or run 4 jobs concurrently with --gres=gpu:1 each.
2. Explorer gpu partition (max 8 h, default 4 h, 105 GPUs incl. 4 nodes × 8 H200, 512 GB RAM, billing weight GPU = 100 CPU) for anything when gyorilab is busy — must checkpoint and chain (template below).
3. Modal A100-40 GB for embarrassingly parallel sweeps that need to finish tonight (10 concurrent GPUs on Starter): ~$10 per 50-epoch Transformer-S, so a 20-run sweep is ~$200 — set the budget guard.
4. Colab L4: interactive debugging, attention/embedding visualisation, nothing > 2 h.
5. Kaggle T4×2: only the inference notebook (the submission must run there offline) and MLP training if a Kaggle-native retrain is required; never 50-epoch transformer training (18 h vs session limits).
6. Local box (32 cores, 135 GB RAM): parquet → flattened arrays conversion, candidate-pool building, scoring. Do not train here.

4. enveda-180 ablation

What is public. I opened seven CASMI-2026 GitHub write-ups (corentinlaudicina, kabir0774, billylu24, OfficialBhattacharya, vicky0718, AmanDubal — mxm-1x and AmanDubal README fetches 404'd). None reports a train-with vs train-without enveda-180 ablation. The single relevant number is in corentinlaudicina/enveda-casmi-2026 README: "Baseline MLP on natural products (enveda-np-examples, train+COCONUT pool) | 0.138 vs 0.107 random: a model trained on enveda-180 alone barely transfers to natural products" (their MLP: 100 strongest peaks, 0.1 Da / 10,000 bins, 2,048-bit Morgan, BCE + 32 same-mass-decoy ranking loss; public LB 0.112 with COCONUT pool, 0.079 with PubChem pool). Kaggle discussion threads could not be read (JS shell; web-search budget for this session was exhausted after the first query), so "nothing public" is a statement about GitHub mirrors, not the Kaggle forum. Verdict: no public with/without ablation exists; design it.

What the file says that changes the design. Instrument type is timsTOF for 1,154,969 training rows and 1,153,785 of them are enveda-180; the other 1,184 are enveda-np-examples (250 molecules). Dropping enveda-180 therefore removes 99.9 % of the hidden-test instrument domain from training. enveda-180 also carries adduct chemistry the public libraries lack: [2M+Na]+ 188,158, [2M+H]+ 89,487, [2M−H]− 52,933, [M+CH2O2−H]− 24,556 spectra. Its 182,941 InChIKey14 overlap the other sources by only 2,288 molecules, so it is also structurally disjoint from everything else. A plain "remove it" ablation confounds chemistry-domain with instrument-domain.

Validation set (one for all runs). NP-holdout: all 250 enveda-np-examples molecules (1,184 spectra, timsTOF — the only in-domain data we have) + 1,750 further InChIKey14 drawn from non-enveda-180 sources whose InChIKey14 is in COCONUT, sampled stratified by precursor m/z decile; every spectrum of a held-out InChIKey14 is removed from training, whatever its source. Candidate pool = COCONUT (Oct 2026 lite, local copy) within ±10 ppm of the neutral mass implied by the adduct. Metrics: MRR@25 (primary), recall@25, and the two slices "timsTOF NP (n = 250)" and "other-instrument NP (n = 1,750)". Seed-triplicate every run; the 0.03 differences that matter here need ±0.01 CIs.

Cost: 7 runs × 3 seeds × ~1.5 h (Transformer-S, 1× H200) ≈ 32 GPU-h ≈ 1.3 days on the 4-GPU node; the MLP version of the grid is < 2 h total and should run first to decide whether the transformer grid is worth it.

Decision rule. If R1 − R0 > +0.01 on the "other-instrument NP" slice but < 0 on the timsTOF slice, enveda-180 is a biased filler for chemistry and a necessary one for instrument — ship R3 or R6. If R2 at w = 0.25 ≥ R0 on both slices, ship R2 (simplest). If R4 beats everything on the timsTOF slice, the model was using library identity as a shortcut.

Forced analogy: jurisprudence of eyewitness line-ups (filler selection)

The analogy, precisely. In a line-up the witness has given a description; fillers must match that description so that the suspect does not stand out for reasons unrelated to memory. Here the hidden test's "description" is: natural product or NP-like, measured on a timsTOF with one of seven adducts. Our candidate pool (COCONUT ± 10 ppm) is the line-up; the true structure is the suspect; the model is the witness. enveda-180 is a set of 182,941 fillers that match half the description — instrument and adduct, yes; chemistry, no (0.03 % COCONUT, 2,288-molecule overlap with the rest of train). A witness trained to tell apart synthetic-looking fillers may at test time "pick out" the candidate that looks least like the training distribution, i.e. the most NP-like one, regardless of the spectrum — or, conversely, push NP-typical substructures (glycosides, polyketide chains) toward low fingerprint probabilities because it never saw them lit up.

Testable derivation — the synthetic-preference index (SPI). For every NP-holdout spectrum build a mixed line-up: the COCONUT candidates within ±10 ppm plus an equal number of mass-matched synthetic decoys drawn from enveda-180 structures held out of training (they exist for every mass window; enveda-180 spans the same precursor range). Rank the mixed pool with model M. SPI(M) = mean rank-percentile of the synthetic decoys (0.5 = unbiased; < 0.5 = the model promotes synthetic-looking structures; > 0.5 = it demotes them). Compute for R0, R1, R2, R6. A second, cheaper probe: predicted-fingerprint drift Δ = mean cos(f̂, f_true) on NP-holdout minus the same on a held-out enveda-180 slice, for each run; if Δ(R0) ≪ Δ(R1) the fingerprint head has specialised to synthetic bit patterns. Both are one evaluation pass each (~2 min on an H200) and give a number before any leaderboard submission.

Does the analogy hold? Partially. It holds for the evaluation side: a biased line-up (a pool whose fillers are systematically unlike the suspect) makes any ranking uninformative, and that is exactly why the public write-ups found PubChem pools (90 M fillers that do not match the description) score 0.079 vs COCONUT 0.112 — filler selection is the candidate-pool question. It breaks on the training side: fillers never train the witness; enveda-180 does. The closer legal concept is mugshot-exposure / "unconscious transference": a witness who browsed thousands of faces before the line-up tends to pick faces that feel familiar for the wrong reason. The practical lesson survives the break: measure the witness's prior (SPI) separately from the line-up's fairness (pool recall@25), because the two failures look identical on MRR.

Gotchas / what could fool us

1. num_peaks max = 73,318 and precursor_mz max = 2,430,333. Row-level garbage exists (profile-mode spectra, unit errors). Filter: precursor_mz ≤ 1,000 (drops 0.86 %), num_peaks ≤ 2,000, no peak > precursor + 3 Da with > 20 % intensity (MassSpecGym's rule). Otherwise a 73 K-peak row blows up a padded batch.
2. Two-thirds of peaks are noise-floor (< 0.1 % base peak). A model with raw-intensity inputs effectively sees ~50 meaningful tokens; a binned MLP that does not sqrt/log-transform intensities sees a one-hot base peak. Use sqrt or log1p(1e4·I).
3. Library-identity shortcut. Peak count, intensity floor and adduct distribution identify enveda-180 almost perfectly (median 138 peaks vs 9–21 in riken/pluskal/massbank). A model can learn "timsTOF-looking ⇒ synthetic chemistry prior" — this is exactly what R4 tests and what the visible (decoy) test set rewards.
4. The visible test set is verbatim enveda-180 rows, so any local score on it is a memorisation score; the NP-holdout above is the only honest local number.
5. Dimer adducts. 24 % of enveda-180 spectra are [2M+·]± adducts; if the hidden test's seven adducts exclude dimers (unverified here), those 330 K spectra contribute nothing but a wrong mass prior — consider dropping them before the ablation, or the R1/R2 effect will be partly a dimer effect.
6. Padding waste and MFU. With median 42 and p90 416 peaks, naive padding to the batch max wastes > 70 % of compute; bucket by length or clip to 100. The throughput table assumes clipping.
7. MFU is assumed, not measured. Every wall-clock in §3 scales linearly with the 25 % guess; run a 200-step benchmark on each target and rewrite the table — expect T4 to be worse than modelled (no BF16, 320 GB/s).
8. Modal price drift. The brief's $1.4/GPU-h does not match the page today ($2.10 for A100-40 GB); budgets should be set from the fetched per-second rates.
9. Explorer gpu partition is 8 h max; a 50-epoch Transformer-L (4.7 h) fits, but a Transformer-S hyperparameter sweep does not unless chained. gyorilab is group-restricted (AllowGroups=rc,gyorilab) — confirm membership with sacctmgr show assoc user=shenoy.am before relying on it.
10. Proxy. http_proxy/https_proxy=http://10.99.0.130:3128 is already exported on explorer-01's login shell; compute nodes need it exported inside the job for pip, HF, Kaggle downloads. Nothing in the rc-docs mentions it; it comes from the environment and the brief.
11. CRLF. Any .sh edited on Windows and copied up fails with sbatch: error: Batch script contains DOS line breaks — run sed -i 's/\r$//' job.sh (dos2unix is not guaranteed on the login node).
12. rsync exists on both ends (/usr/bin/rsync on explorer-01; rtools45 rsync locally) but the local one is a Cygwin build whose path mapping and ssh invocation differ from Git Bash's scp; the "scp not rsync" rule is a Windows-side problem. Use scp or rclone/Globus via xfer.discovery.neu.edu (the documented transfer node), not explorer-01.
13. /scratch is 91 % full (1.4 of 1.5 PB) and not backed up; stage 1 GB of flattened arrays, not 48 GB of binned tensors, and copy checkpoints home.

Explorer sbatch template (copy-paste; strip CR before submitting)

#!/bin/bash
#SBATCH --job-name=casmi_tfS
#SBATCH --partition=gyorilab,gpu        # gyorilab: 4xH200, 30 d max; gpu: 8 h max — whichever starts first
#SBATCH --gres=gpu:1
#SBATCH --cpus-per-task=12
#SBATCH --mem=128G
#SBATCH --time=07:50:00                 # under the gpu partition's 8:00:00 MaxTime; harmless on gyorilab
#SBATCH --array=1-6%1                   # chain: 6 sequential 8-h slots = 48 h budget, resume from checkpoint
#SBATCH --signal=B:USR1@600             # 10 min before the limit, let the script checkpoint
#SBATCH --output=/scratch/shenoy.am/casmi26/logs/%x_%A_%a.out
#SBATCH --error=/scratch/shenoy.am/casmi26/logs/%x_%A_%a.err
set -euo pipefail
export http_proxy=http://10.99.0.130:3128 https_proxy=http://10.99.0.130:3128 ftp_proxy=http://10.99.0.130:3128
export HF_HOME=/scratch/shenoy.am/hf  TOKENIZERS_PARALLELISM=false  OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
module load explorer anaconda3/2024.06 cuda/12.8.0      # cuda modules present: 12.1.1 12.3.0 12.8.0 13.2.0
source activate casmi26
RUN=/scratch/shenoy.am/casmi26/runs/${SLURM_JOB_NAME}_${SLURM_ARRAY_JOB_ID}
mkdir -p "$RUN"
CKPT=$(ls -t "$RUN"/ckpt_*.pt 2>/dev/null | head -1 || true)
trap 'echo "USR1: checkpointing"; kill -USR1 $PID; wait $PID' USR1   # train.py saves on SIGUSR1 and exits 0
python -u train.py --data /scratch/shenoy.am/casmi26/flat_top100 --out "$RUN" \
    --epochs 50 --batch 2048 --bf16 ${CKPT:+--resume "$CKPT"} &
PID=$!; wait $PID; RC=$?
# done? cancel the remaining array tasks so the chain stops
if [ -f "$RUN/DONE" ]; then scancel --state=PENDING "$SLURM_ARRAY_JOB_ID"; fi
exit $RC

Rules of use: the script must write ckpt_<epoch>.pt (model + optimizer + scheduler + RNG + epoch) every ~15 min (rc-docs recommends 10–15 min) and on SIGUSR1, and touch DONE after the last epoch. For 4-GPU DDP on gyorilab change to --gres=gpu:4 --ntasks-per-node=4 --cpus-per-task=12 and launch with srun torchrun --nproc_per_node=4 .... Submit with sed -i 's/\r$//' job.sh && sbatch job.sh; stage data with scp -r C:/Temp/casmi26/flat_top100 shenoy.am@xfer.discovery.neu.edu:/scratch/shenoy.am/casmi26/. Monitor with squeue -u shenoy.am and sacct -j <id> --format=JobID,Elapsed,MaxRSS,State.

Implications for the challenge

1. Convert train.parquet once to the flattened top-100 layout (0.80 GB) and put that, not parquet, on every machine; it removes the data loader from the critical path on all five targets.
2. Use Fourier m/z features (6,000-d, DreaMS/MassSpecGym recipe) in any peak-token model; the published 7× hit@1 gain is the cheapest known win.
3. Run the MLP version of the R0–R6 grid first (< 2 h on one H200) and read the NP-holdout MRR@25 on the timsTOF and other-instrument slices before spending 32 GPU-h on the transformer grid.
4. Do not simply drop enveda-180: it is 99.9 % of the timsTOF spectra in train. Prefer R2 (w = 0.25), R3 (pretrain-then-finetune) or R6 (self-supervised use only) and let the data choose.
5. Report SPI and recall@25 beside MRR for every model so "biased witness" and "biased line-up" failures are told apart.
6. Keep all 50-epoch transformer training on Explorer (gyorilab first, gpu with the chained-array template second); spend Modal (~$10 per Transformer-S run) only on parallel sweeps with a hard budget; Kaggle T4s are for the inference notebook.
7. Filter the 0.86 % precursor > 1,000 Da rows and cap num_peaks before any batch padding; the 73 K-peak row will OOM a padded batch.
8. Benchmark MFU on each target for 200 steps and overwrite the §3 table with measured epoch times before planning the final week.

Open questions

• Kaggle code-competition limits (max notebook runtime, GPU allowed, RAM) are unverified — the Kaggle pages are JS shells; a GitHub mirror of the rules is needed.
• Colab L4 compute-unit burn rate and Pro+ monthly allocation: unverified (pricing page not fetchable).
• Are the hidden test's seven adducts free of dimers? If so, 24 % of enveda-180 is deadweight and should be excluded before the ablation.
• Is shenoy.am in the gyorilab Slurm group? (AllowGroups=rc,gyorilab.) One sacctmgr call settles it.
• MIST parameter count and its own paper's hardware/time: not retrievable today (Nature paywall, bioRxiv 429); the A100/5 h figure is MassSpecGym's reproduction, not Goldman's.
• True MFU of a 25 M-param, 61-token model on H200/T4 — only a benchmark will tell; the table could be off by 2× either way.

Sources

• MassSpecGym paper, arXiv 2410.23326v3 (PDF, appendices 2.3, 3.1–3.3, Tables 2–6): https://arxiv.org/pdf/2410.23326
• MassSpecGym README: https://raw.githubusercontent.com/pluskal-lab/MassSpecGym/main/README.md ; HF dataset card https://huggingface.co/datasets/roman-bushuiev/MassSpecGym
• DreaMS, Bushuiev et al., Nat Biotechnol 2025, doi:10.1038/s41587-025-02663-3, full text via Europe PMC PMC13090125: https://www.ebi.ac.uk/europepmc/webservices/rest/PMC13090125/fullTextXML ; README https://raw.githubusercontent.com/pluskal-lab/DreaMS/main/README.md ; model code https://raw.githubusercontent.com/pluskal-lab/DreaMS/main/dreams/models/dreams/dreams.py
• MIST: Goldman et al., Nat Mach Intell 2023, doi:10.1038/s42256-023-00708-3 (abstract-level access only); repo README (master, main_v2) and config https://raw.githubusercontent.com/samgoldman97/mist/main_v2/configs/canopus_compare/canopus_fp_mist.yaml , canopus_fp_ffn.yaml
• MassFormer: arXiv 2111.04824 (ar5iv HTML https://ar5iv.labs.arxiv.org/html/2111.04824 ); repo README https://raw.githubusercontent.com/Roestlab/massformer/master/README.md
• Modal pricing: https://modal.com/pricing (fetched 2026-10-07)
• NVIDIA pages: H200 https://www.nvidia.com/en-us/data-center/h200/ ; H100 https://www.nvidia.com/en-us/data-center/h100/ ; L4 https://www.nvidia.com/en-gb/data-center/l4/ ; T4 https://www.nvidia.com/en-us/data-center/tesla-t4/ ; A100 https://www.nvidia.com/en-us/data-center/a100/ ; Wikipedia Hopper and Ampere microarchitecture tables (dense BF16 figures)
• NEU RC docs: https://rc-docs.northeastern.edu/en/latest/gpus/quickstart-h200.html , gpus/gpujobsubmission.html , gpus/multigpu-partition-access.html , best-practices/checkpointing.html , datamanagement/transferringdata.html , runningjobs/interactiveandbatch.html , runningjobs/slurmarray.html
• Explorer live queries (2026-10-07, ssh explorer): sinfo -p gyorilab,gpu,..., scontrol show partition gyorilab|gpu, env | grep proxy, module avail cuda, df -h /scratch
• CASMI-2026 public write-ups opened: https://github.com/corentinlaudicina/enveda-casmi-2026 (README), https://github.com/kabir0774/Enveda-Casmi-2026 , https://github.com/billylu24/Enveda-CASMI-2026---Molecule-ID-From-Mass-Spectra , https://github.com/OfficialBhattacharya/kaggle_CASMI_2026 , https://github.com/vicky0718/Enveda-CASMI2026 (mxm-1x and AmanDubal READMEs returned 404)
• Local measurements: C:\Temp\casmi26\data\train.parquet (Kaggle CLI, 2026-10-07), scripts stats.py, stats2.py in the worker scratchpad; outputs reproduced in §1 and §4.