Training your own ChromBPNet model is where the framework stops being something you read about and becomes an instrument tuned to your biology. A model trained on your ATAC-seq data learns the accessibility grammar of your exact cell type, in your conditions, which no shared model can fully do for you. The work follows a clear pipeline: prepare the data, train a bias model, train the accessibility model, and then check what you built. This guide walks through each stage, what it needs, what it produces, and the judgment calls along the way, so your first training run is a planned exercise rather than a leap of faith.
When training your own model makes sense
Train your own model when your cell type, treatment, or species is not covered by the pretrained models the project shares, or when your scientific question depends on your own dataset specifically. A differentiation time course, a rare primary cell type, a drug perturbation: these are exactly the cases where accessibility patterns diverge from reference data and a custom model earns its compute.
If a pretrained model already exists for your cell type and you only need predictions or variant scores, start there instead. Training is the expensive path, and it is worth taking when the biology demands it, not as a rite of passage.
Stage 1: Prepare the data
Everything downstream depends on this stage, and it is the least glamorous one. Data preparation builds the training regions from three inputs:
- Peak regions called from your ATAC-seq experiment, the accessible regions your model will learn from.
- The reference genome those peaks come from, which supplies the actual DNA sequence for every region.
- The accessibility signal itself, from your experiment’s read data, the fragment or alignment files produced by the assay.
Preparation also selects negative regions, the non-peak stretches the pipeline calls non-peaks, matched to your peaks. These matched negatives matter twice over. They teach the model what closed or background sequence looks like, and, in a later stage, they give the bias model regions with no real accessibility signal to learn from. Take the time to confirm that your peaks, your genome build, and your signal files all describe the same coordinates and the same cell type. Mismatches here do not always crash; sometimes they quietly produce a model that learned a shifted, diluted version of your data.
Stage 2: Train the bias model
Before the main model sees any data, you train the bias model. Its job is narrow and important: learn the sequence preferences of the assay enzyme, Tn5 in the case of ATAC-seq, from regions that carry no real accessibility signal. Because those regions have no genuine biology to explain, whatever sequence pattern the bias model picks up is enzyme preference by construction.
Skipping this stage is the classic false economy of ChromBPNet training. Without it, the accessibility model spends part of its capacity explaining enzyme taste, and the motifs you later extract are contaminated with bias artifacts. The two-stage design exists precisely to prevent that, and the stage is cheap compared with the main training run. Run it, every time.
Stage 3: Train the accessibility model
With the bias model trained, the main event begins: the bias-factorized accessibility model. This network learns to predict, for each training region, the base-resolution accessibility profile and the total read count, with the enzyme bias already accounted for by the bias component. What remains for it to learn is the biology: the sequence determinants of real openness in your cell type.
This is the compute-heavy stage, and it is why the install guide insists on a CUDA-capable NVIDIA GPU. The model processes many long sequence regions, memory use runs high, and training takes real time. Plan the run like an experiment:
- Start the run and watch the first stretch of training rather than walking away immediately.
- Check that the training loss is actually improving; a flat loss early on is information, not bad luck.
- Keep notes on the dataset version, peak set, and settings you used, so the finished model is reproducible.
Checking a freshly trained model
A finished training run gives you files, not confidence. Build confidence with checks that mirror how you will actually use the model. Predict profiles for regions the model did not train on and compare their shapes against the measured signal: peaks should line up where the experiment says accessibility lives, and predicted totals should track the real strength of regions rather than collapsing to a flat average. Flat predictions on real peaks usually mean the model is undertrained, or that peaks and signal from different cell types were mixed during preparation, and both are fixable once spotted.
Then run a quick interpretation pass. Even a rough look at contribution scores on a few strong peaks tells you if the model is keying on plausible sequence patterns. You are not publishing motifs yet; you are confirming the model learned signal worth interpreting, before you invest in full interpretation or variant scoring.
What the trained model unlocks
A validated model for your cell type supports the three working modes of the framework. You can predict base-resolution profiles for any region you can write down as sequence, including engineered or hypothetical sequences. You can interpret the model properly with contribution scores and TF-MoDISco, and recover the transcription factor motifs it relies on in your cell type. And you can score variants, comparing reference and variant sequence predictions to estimate which noncoding variants in your system actually move accessibility. That last ability is often the entire reason the model was trained, since variant interpretation in a generic cell type can miss effects that only appear in yours.
Iterating: treat the first model as a draft
Few groups keep their first trained model. The first run teaches you how your particular dataset behaves inside the pipeline: whether the peak set holds together, whether the loss descends the way a healthy run should, whether early predictions on held-out regions track the measured signal. Expect to loop back to preparation with what you learned, tighten the peak set or fix a provenance mix-up, and train again. This is normal scientific iteration, not failure, and it is far cheaper to discover dataset problems in a first training run than in a variant-scoring table six months later.
Make the loop cheap by keeping versions straight. Save each trained model alongside the exact inputs and settings that produced it, so a better second model can be compared against the first honestly, region by region and motif by motif. The groups that get the most from ChromBPNet are rarely the ones with the biggest GPU. They are the ones whose models come with a paper trail.
Conclusion
Training a ChromBPNet model is a pipeline with a logic you can hold in your head: prepare peaks, matched non-peaks, genome, and signal that all agree with each other; train the bias model so the enzyme’s preferences are accounted for; then train the bias-factorized accessibility model on a GPU and check it against held-out signal before trusting it. Respect the preparation stage, never skip the bias stage, and validate before you interpret. Do those three things and the model you get back is one you can defend in a lab meeting, which is the only kind worth training.
Read next:
Pingback: chrombpnet Inputs Explained: Peaks, Genome and Signal
Pingback: How chrombpnet Removes Tn5 Bias: The Bias Model