Help troubleshooting Relion5 Refine3D crash with Warp-processed tomo particles

[Wanlong Hu]

Hi all,

I am trying to set up a tomogram refinement workflow in Relion 5.0 with data pre-processed in Warp. I followed the routine workflow in our lab and adapted some of the steps:

My project structure looks like this (simplified):

project_folder/ 

 ├─tomograms/

 │ ├─ SMV031825_43002/

 │ │ ├─ SMV031825_43002.mrc # tilt series stack 

 │ │ ├─ SMV031825_43002.xf

 │ │ ├─ SMV031825_43002.tlt 

 │ │ ├─ SMV031825_43002_test.csv # order list

 │ └─ ... 

 ├─ frames/ 

 ├─ tomostar/ 

 ├─ particles/

 ├─ warp_frameseries/ 

 ├─ warp_tiltseries/ 

 ├─ warp4relion/

My pipeline was:

1. Split IMOD tilt series into MRC images → WarpTools create_settings → WarpTools fs_ctf.

2. Generate .tomostar files using order list CSV

3. WarpTools create_settings → WarpTools ts_import_alignments → WarpTools ts_ctf.

4. Convert previous refined bin1 particles in Relion 4 to per-tomo .star files.

5. Export particle coordinates with WarpTools ts_export_particles.

6. Feed the resulting particle .star files into Relion 5 Refine3D.

Everything runs fine up to this point, but Refine3D always crashes immediately after the first iteration when I run bin1 refinement. The error message is:

corrupted double-linked list [cm-g10:3910872] *** Process received signal *** [cm-g10:3910872] Signal: Aborted (6) [cm-g10:3910872] Signal code: (-6) [cm-g10:3910872] [ 0] /lib64/libpthread.so.0(+0x12cf0)[0x14c3078c8cf0] [cm-g10:3910872] [ 1] /lib64/libc.so.6(gsignal+0x10f)[0x14c3067cfaff] [cm-g10:3910872] [ 2] /lib64/libc.so.6(abort+0x127)[0x14c3067a2ea5] [cm-g10:3910872] [ 3] /lib64/libc.so.6(+0x91097)[0x14c306812097] [cm-g10:3910872] [ 4] /lib64/libc.so.6(+0x984ec)[0x14c3068194ec] [cm-g10:3910872] [ 5] /lib64/libc.so.6(+0x98d2c)[0x14c306819d2c] [cm-g10:3910872] [ 6] /lib64/libc.so.6(+0x9b8ab)[0x14c30681c8ab] [cm-g10:3910872] [ 7] /lib64/libc.so.6(+0x9be0b)[0x14c30681ce0b] [cm-g10:3910872] [ 8] /lib64/libc.so.6(+0x9ce6a)[0x14c30681de6a] [cm-g10:3910872] [ 9] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_malloc_plain+0x15)[0x14c30d2cffd5] [cm-g10:3910872] [10] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_mktensor+0x3a)[0x14c30d2d44ba] [cm-g10:3910872] [11] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_tensor_copy_except+0x16)[0x14c30d2d4dd6] [cm-g10:3910872] [12] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_mkproblem_rdft2+0x77)[0x14c30d31b607] [cm-g10:3910872] [13] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_mkproblem_rdft2_d+0x18)[0x14c30d31b718] [cm-g10:3910872] [14] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(+0x66eea)[0x14c30d31aeea] [cm-g10:3910872] [15] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(+0x1e492)[0x14c30d2d2492] [cm-g10:3910872] [16] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(+0x1ec06)[0x14c30d2d2c06] [cm-g10:3910872] [17] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(+0xf15d8)[0x14c30d3a55d8] [cm-g10:3910872] [18] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_mkapiplan+0xde)[0x14c30d3a57ce] [cm-g10:3910872] [19] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_plan_many_dft_r2c+0x13e)[0x14c30d3ac69e] [cm-g10:3910872] [20] /software/relion/5.0_gpu_ompi4/lib/libfftw3.so.3(fftw_plan_dft_r2c+0x25)[0x14c30d3abc45] [cm-g10:3910872] [21] /software/relion/5.0_gpu_ompi4/bin/relion_refine_mpi(_ZN18FourierTransformer7setRealER13MultidimArrayIdEb+0xc5)[0x580225] [cm-g10:3910872] [22] /software/relion/5.0_gpu_ompi4/bin/relion_refine_mpi(_ZN13BackProjector11reconstructER13MultidimArrayIdEibRKS1_ddibP5ImageIdE+0x15d)[0x5586ad] [cm-g10:3910872] [23] /software/relion/5.0_gpu_ompi4/bin/relion_refine_mpi(_ZN14MlOptimiserMpi12maximizationEv+0x16d6)[0x4cbec6] [cm-g10:3910872] [24] /software/relion/5.0_gpu_ompi4/bin/relion_refine_mpi(_ZN14MlOptimiserMpi7iterateEv+0x397)[0x4cd0b7] [cm-g10:3910872] [25] /software/relion/5.0_gpu_ompi4/bin/relion_refine_mpi(main+0x52)[0x486732] [cm-g10:3910872] [26] /lib64/libc.so.6(__libc_start_main+0xe5)[0x14c3067bbd85] [cm-g10:3910872] [27] /software/relion/5.0_gpu_ompi4/bin/relion_refine_mpi(_start+0x2e)[0x48a03e] [cm-g10:3910872] *** End of error message *** -------------------------------------------------------------------------- Primary job terminated normally, but 1 process returned a non-zero exit code. Per user-direction, the job has been aborted. -------------------------------------------------------------------------- -------------------------------------------------------------------------- mpirun noticed that process rank 2 with PID 3910872 on node cm-g10 exited on signal 6 (Aborted).  

---

My questions:

1. Is ts_reconstruct a required step before running Refine3D on Warp-exported particles? I did not include it in the workflow. Of course I would do this step latter, but this may take a lot of time.

2. Has anyone seen similar errors in Relion? Because the dataset had been refined to 8.56 Å in bin1, I dont think it's Relion's fault...

Any advice or experience would be greatly appreciated!

Best wishes,

Wanlong

P.S. the following are detailed steps, if you are interested, you can find related scripts on github.

# Split IMOD-processed tilt series stacks into individual MRC images using .tlt angle files.

python script/split_tiltstack.py -i tomograms/ -o frames/ --workers 16 --recursive

WarpTools create_settings \

--folder_data frames \

--folder_processing warp_frameseries \

--output warp_frameseries.settings \

--extension "*.mrc" \

--angpix 1.571 \

--exposure 3

 

WarpTools fs_ctf \

--settings warp_frameseries.settings \

--grid 2x2x1 \

--range_max 7 \

--defocus_max 8 \

--use_sum \

--perdevice 4

WarpTools filter_quality --settings warp_frameseries.settings --histograms

 

cd warp_frameseries

ln -s ../frames average

cd ..

# Generate .tomostar files for Warp from IMOD-processed tilt series using order CSV and frame averages.

python script/generate_tomostar.py -i tomograms/ -f frames/ -o tomostar/--recursive --workers 16

# --tomo_dimensions is the original dimension defined in emClarity in this case (convert_emClarity2relion.m).

WarpTools create_settings \

--output warp_tiltseries.settings \

--folder_processing warp_tiltseries \

--folder_data tomostar \

--extension "*.tomostar" \

--angpix 1.571 \

--exposure 3 \

--tomo_dimensions 4096x4096x3000

 

WarpTools ts_import_alignments \

--settings warp_tiltseries.settings \

--alignments tomograms/ \

--alignment_angpix 6.284

WarpTools ts_defocus_hand --settings warp_tiltseries.settings --check

 

WarpTools ts_ctf \

--settings warp_tiltseries.settings \

--range_high 7 \

--defocus_max 8 \

--perdevice 4

WarpTools filter_quality --settings warp_tiltseries.settings --histograms

 

# Split particles from a multi-tomogram STAR into per-tomo STARs after applying recenter and local shift, then bin coordinates.

# In this case, the particles has been refined in bin1, so doing bin4 to match the aligned tomograms.

python script/generate_particlestar.py -i relion/Refine3D/job051/run_data.star -o particles -b 4

 

WarpTools ts_export_particles \

--settings warp_tiltseries.settings \

--input_directory particles \

--input_pattern "*.star" \

--coords_angpix 6.284 \

--output_star warp4relion/matching.star \

--output_angpix 1.571 \

--box 240 \

--diameter 240 \

--relative_output_paths \

--2d \

--perdevice 4

 

cd warp4relion

cp ../relion/Refine3D/job051/run_class001.mrc ./

ml relion/5.0_gpu_ompi4_cuda111

relion --tomo&

Refine3D:

  Input optimisation set: matching_optimisation_set.star

  Reference map: run_class001.mrc

  Initial low-pass filter 20

  Symmetry C10

  Mask diameter 240

  Initial angular sampling 1.8

  Local searches from auto-sampling 1.8

  Use GPU acceleration

  --sigma_ang 2

I tried a lot of parameters in Relion 5, but all same errors...

[Alister Burt]

Hi Wanlong,

No immediate answers but I would recommend

1. Verifying that the tutorial runs successfully in your system (to see whether this is a problem with your RELION installation, your data or your processing, or warp/M)

2. Carefully assessing how metadata from your processing is similar/differs from metadata from (1) assuming (1) was successful 

3. Making sure this isn’t a memory issue by running with small box size/number of particles (seems like you may have done this)

You don’t need to reconstruct tomograms but you should make sure your reconstruction density and geometry matches the tomograms you did your picking in exactly as there are many ways this can differ.

Cheers and I hope you can figure it out! 

Alister 

Sent from mobile - apologies for brevity

[Wanlong Hu]

Hi Alister,

I have run the tutorial smoothly in our system, solving the resolution of apoferritin to 2.78  Å.

I notice that there are FlipYZ and FlipZ during initial relion TomoImport job, but I did not flip anything during this workflow. I think this might be the issue, and I would try to determine whether particles' locations are right.

Best,

Wanlong

[Wanlong Hu]

Hi Alister,

By the way, do you know whether there are existing scripts I can do FlipYZ or FlipZ to my particle coordinates? And does warp-tm-vis only run on linux? I installed it on Windows 11 with python version 3.9.12, but it report errors:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\14750\AppData\Local\uv\cache\archive-v0\qrmkow8IjsgxbFKp1u_1f\Scripts\warp-tm-vis.exe\__main__.py", line 4, in <module>
  File "C:\Users\14750\AppData\Local\uv\cache\archive-v0\qrmkow8IjsgxbFKp1u_1f\Lib\site-packages\warp_tm_vis\cli.py", line 18, in <module>
    console = rich.console.Console()
              ^^^^^^^^^^^^
AttributeError: module 'rich' has no attribute 'console'. Did you mean: '_console'?

Best,

Wanlong

[Alister Burt]

Hi Wanlong,

Flipping coords through the XY plane (flipz in your message) is a non trivial transformation to your particle poses - position is fine and relatively simple but the handedness of the density ends up flipped so you have to reconstruct the coordinate system of the transformed particle carefully if you want to maintain it after flipping… probably these scripts exist but I haven’t written them, happy to provide pointers

Re: warp-tm-vis, sorry about the issue - should run on windows but wasnt developed/tested there, looks like you’re hitting https://github.com/warpem/warp-tm-vis/issues/9 and Doulin posted a workaround there, I’ll push an update tomorrow to fix this for all :-)

Cheers,

Alister

Sent from mobile - apologies for brevity

On Sep 23, 2025, at 23:29, Wanlong Hu <yunluoc...@gmail.com> wrote:

Hi Alister,

--
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/17785ea2-f260-43db-86ea-48b74244d61cn%40googlegroups.com.

[Wanlong Hu]

Hi Alister,

Thanks for your clarification. For now I don't care about the handedness. I checked the Warp-reconstructed tomograms and their coordinate system seemed matching with the particle's positions I exported from Relion. So I dont think it's Flip's issue now. Of course I would use your useful visulization tool to check it latter. Thank you for your contribution to this field :-)

My another attempt is to average all the Warp-exported particles to check whether the particle stacks are right. However, when I check warp src code (https://github.com/warpem/warp/blob/main/WarpLib/TiltSeries/TiltSeries.ReconstructParticleSeries.cs), I find that Warp seems just summing the particles together without considering their orientations. Is my understanding right? If so, this quality indicator might be less useful for most cases.

Cheers,

Wanlong

[Wanlong Hu]

Hi Alister,

Thanks for your clarification and contribution. Of course I would use your useful visulization tool to check the particles latter. Frankly I find the coordinate system of Warp-reconstructed tomograms seems matching with my particle's positions, and I don't think it is Flip that caused the issue now.

My another attempt is to average all my particles together to check whether they are right. However, I find that Warp seems just summing particles together without considering orientations (https://github.com/warpem/warp/blob/main/WarpLib/TiltSeries/TiltSeries.ReconstructParticleSeries.cs). Is my understanding right?

Cheers,

Wanlong

在2025年9月24日星期三 UTC+8 19:40:26<alist...@gmail.com> 写道：

[Alister Burt]

Hi Wanlong,

Sorry for the delay in your messages showing up, they were marked as potential spam and had to be manually approved.

This is getting a bit chaotic, I see two questions (one in private email)

- why is warp simply summing particle images in the linked method?

- why is rlnTomoImportFractionalDose incorrect in your tomograms.star file?

The summing and saving of particle images per tilt series is only meant to provide a basic visual check that your particle images are indeed roughly centered correctly - these outputs are not used for any downstream processing. This is described in the tutorial https://warpem.github.io/user_guide/warptools/quick_start_warptools_tilt_series/#export-particles

I don't know why this particular entry is incorrect but I would carefully check the results of ts_import and the contents of your mdoc files - the value had to come from somewhere.

In any case, you said that correcting it did not fix your RELION crashes so I don't see how this is relevant to your problems with RELION.

Cheers and I hope you can get this figured out!

Alister

To view this discussion visit https://groups.google.com/d/msgid/warp-em/40318cd7-13e9-44b6-83f6-d334ddd51b21n%40googlegroups.com.

[Wanlong Hu]

Hi Alister,

I would like to report my progress and seek your advice. 

1. In some tomograms, the second tilt during data collection was deleted. Because the rlnTomoImportFractionalDose was computed by subtracting the dose of the first tilt from that of the second (source code line 893-903), it would generate wrong dose in this case. I manually corrected them.

2. I customized your warp-tm-vis for our dataset (tm-vis), and confirmed that the particle positions were wrong in Warp-reconstructed tomograms. Furthermore, I found that the z-axis orientation of the Relion-reconstructed tomogram was opposite to that of the Warp-reconstructed tomogram, and particles looked right in Relion-reconstructed tomograms. You can check the attached  screenshot: The left was generated by WarpTools ts_reconstruct, and the right by relion_tomo_reconstruct_tomogram.

Since there is no mdoc file, I made tomostar files by my own script (generate_tomostar), WarpTools create_settings, and then WarpTools ts_import_alignments. I don't know how I can generate z-flipped tomograms using Warp. The other idea might be flipping the z of particles, but I am not sure what transformation I should do for Euler angles. Do you have any suggestions for these two paths? I appreciate your time and guidance.

Cheers,

Wanlong

[Alister Burt]

Hi Wanlong, responses inline below

Sent from mobile - apologies for brevity

On Oct 8, 2025, at 01:21, Wanlong Hu <yunluoc...@gmail.com> wrote:

Hi Alister,

I would like to report my progress and seek your advice. 

1. In some tomograms, the second tilt during data collection was deleted. Because the rlnTomoImportFractionalDose was computed by subtracting the dose of the first tilt from that of the second (source code line 893-903), it would generate wrong dose in this case. I manually corrected them.

This makes sense, is an edge case we can’t really do much about so I’m glad you’ve solved it yourself

2. I customized your warp-tm-vis for our dataset (tm-vis), and confirmed that the particle positions were wrong in Warp-reconstructed tomograms.

👍 

Furthermore, I found that the z-axis orientation of the Relion-reconstructed tomogram was opposite to that of the Warp-reconstructed tomogram, and particles looked right in Relion-reconstructed tomograms. You can check the attached  screenshot: The left was generated by WarpTools ts_reconstruct, and the right by relion_tomo_reconstruct_tomogram.

Yep - getting consistent coordinate systems between the various tomo packages is a huge pain

Since there is no mdoc file, I made tomostar files by my own script (generate_tomostar), WarpTools create_settings, and then WarpTools ts_import_alignments. I don't know how I can generate z-flipped tomograms using Warp.

Flip your tilt angles

The other idea might be flipping the z of particles, but I am not sure what transformation I should do for Euler angles. Do you have any suggestions for these two paths? I appreciate your time and guidance.

You can do this but you also need to mirror your orientations which is less trivial - I suggest flipping your tilt angles as a first step

Great work, always nice to see people delving deep!

Cheers,

Alister

Cheers,

Wanlong

To view this discussion visit https://groups.google.com/d/msgid/warp-em/55200a01-6a82-4576-9a02-b0822f37e681n%40googlegroups.com.

<warp-relion-tomo-compare.png>

[Wanlong Hu]

Hi Alister,

Thanks for your clear sugesstion. I'll try flip tilt angles and record my progress here. I really appreciate your help.

Cheers,

Wanlong

[Wanlong Hu]

Hi all,

I have run through Warp/M successfully for our data. We not only achieved higher resolution but also restore more density. The workflow is here for anyone wants to try. Thanks for many meaningful discussions here.

Thanks,
Wanlong

[Alister Burt]

Hi Wanlong,

I’m glad you got sorted, great work and thanks for sharing publicly!

Cheers,

Alister

Sent from mobile - apologies for brevity

On Oct 13, 2025, at 02:04, Wanlong Hu <yunluoc...@gmail.com> wrote:

Hi all,

To view this discussion visit https://groups.google.com/d/msgid/warp-em/d72bb5b0-2854-42d1-8178-35c4379bab47n%40googlegroups.com.