Crashing at M - Weights (Per-Tilt, Averaged over all Tilt Series)
Dylan Noone
Hi all,
I’m running into an issue during refinement in M and was hoping to get some input from the community.
I am refining bacterial ribosome particles following a workflow similar to the tutorial:
create population → create source → create mask → create species → M CTF refinement #1 → M refinement → CTF refinement #2 → M stage angle refinement → M magnification/Cs/Zernike3 → M weight per tilt series.
The problem arises at the stage where weights are estimated per tilt, averaged over all tilt series. As part of a larger SLURM submission script, I run:
EstimateWeights \
--population m/22586.population \
--source 22586.source \
--resolve_frames
The job begins normally, iterating through tilt series (“Discovering items with data…”), but then fails during:
Loading correlation data...
Loading correlation data... 1/182
With the following error:
Unhandled exception. System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index') at System.Collections.Generic.List`1.get_Item(Int32 index at EstimateWeights.EstimateWeights.Main(String[] args) in .../EstimateWeights.cs:line 339
For context, the preceding step ran successfully:
EstimateWeights \
--population m/22586.population \
--source 22586 \
--resolve_items
MCore \
--population m/22586.population
This leads me to suspect that the issue is specifically related to the --resolve_frames argument. I have attempted some troubleshooting but have not been able to identify the cause.
If anyone has encountered a similar issue or has suggestions on what might be going wrong, I would greatly appreciate your input.
Many thanks in advance,
Dylan
Warp Bot
This is a known bug in EstimateWeights when running with --resolve_frames. The crash occurs because the pre-allocated array size is determined from the first tilt series' FSC file (EstimateWeights.cs, around line 289), but if a subsequent tilt series has a different number of tilts, the index goes out of bounds at line 339.
Another user reported the same crash with the same stack trace in October 2025, and it was confirmed as a bug by the developers.
As a workaround, you can skip the --resolve_frames step for now. The per-item weight estimation (--resolve_items) that you already ran successfully should still give you reasonable weighting for your refinement. The per-frame weights are an additional refinement that is not strictly necessary to get good results.
I have filed a GitHub issue to track this fix.
-- Warp Bot
THIS IS AN AUTOMATED MESSAGE GENERATED BY AN LLM. IT MAY OR MAY NOT SOLVE YOUR PROBLEM. IF YOU'D LIKE TO SPEAK TO A HUMAN, SAY SO IN YOUR MESSAGE.
--
You received this message because you are subscribed to the Google Groups "Warp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to warp-em+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/warp-em/dff47584-08ee-4027-9454-9920114ea1a2n%40googlegroups.com.