DUNEuro computation stalls/runs indefinitely on Linux server with SimNIBS FEM mesh

Bugs
,
1

Dear Brainstorm community,

I am currently facing an issue with the DUNEuro FEM forward computation in Brainstorm and would appreciate any suggestions.

System & Environment

  • OS: Linux server (Ubuntu), accessed via SSH with X11 forwarding

  • MATLAB: R2022b (running in -nodesktop -nosplash mode, inside a tmux session)

  • Brainstorm: Latest version (as of June 2026)

  • DUNEuro Plugin: Downloaded via Brainstorm, using the Linux binary

  • FEM Mesh: Generated with SimNIBS 4.1.0 (CHARM, 12-layer model). The mesh has ~811k nodes and ~4.5M tetrahedra.

Problem Description

The DUNEuro computation starts normally, the terminal log shows that the mesh is being read (Reading 3d Gmsh grid...), and the process runs for a long time (sometimes over 24 hours). However, it never completes. The process does not terminate with an explicit error message; it simply runs indefinitely or the MATLAB process appears to stall with no further output in the terminal.

I have been monitoring the process using htop, and the MATLAB process consumes ~100% CPU, indicating it is performing some computation, but it never reaches the "Computation finished successfully" stage. The process eventually appears to hang, and the terminal shows no additional log messages for hours.

Additional Log Output (last messages before stall)

Below is the last output I see in the terminal before the process stalls indefinitely:

text

DUNEURO> Writing temporary files to: /home/xucs/.brainstorm/tmp/duneuro_260616_191713
DUNEURO> System call: "/home/xucs/.brainstorm/plugins/duneuro/bst_duneuro/bin/bst_duneuro_meeg_linux64.app" "/home/xucs/.brainstorm/tmp/duneuro_260616_191713/duneuro_minifile.mini"
Reading 3d Gmsh grid...
version 2.2 Gmsh file detected
file contains 811226 nodes
file contains 4567499 elements
number of real vertices = 811226
number of boundary elements = 0
number of elements = 4567499
volume_conductor.time_reading_gmsh = 129.446
tensors = 12
time = 0.0187323
volume_conductor.time_reading_tensors = 0.0187617
volume_conductor.time_reordering_indices = 0.324771
volume_conductor.time = 129.789
degree = 1
element_type = tetrahedron
WARNING: You are using AMG without SuperLU! Please consider installing SuperLU, or set the usesuperlu flag to false to suppress this warning.

After this point, there is no further output. The process continues to consume CPU (as seen in htop) but produces no additional log messages for hours. I have attached a screenshot of the htop output showing the MATLAB process consuming ~100% CPU.

Steps Already Taken

  1. Adjusted Computation Parameters: I reduced the source grid parameters from a higher setting (25 layers, 6000 initial vertices) down to the Brainstorm default values (17 layers, 4000 initial vertices). The stalling behavior persists.

  2. Verified Environment: All necessary dependencies (including libldl.so.2 and other SuiteSparse libraries) have been manually installed in a local directory and added to LD_LIBRARY_PATH to resolve the "shared libraries not found" error, allowing the DUNEuro binary to be called successfully from MATLAB.

  3. Checked Warnings: The log shows the common warning WARNING: You are using AMG without SuperLU!. I am aware that installing SuperLU may improve solver performance, but based on forum discussions, a lack of SuperLU should not prevent the computation from completing. I also tried switching the FEM Solver Type between CG and DG, as well as the Source Model between Venant, Subtraction, and Partial Integration, with no improvement.

  4. Tested on a simpler setup: To isolate the problem, I tried the same process using a simpler OpenMEEG BEM head model on the same subject. This completed successfully, confirming that the electrode positions and subject data are valid, and pointing to an issue specific to the FEM/DUNEuro pipeline.

Questions

  1. What could be causing the process to stall indefinitely?

    • Could this be a memory issue (despite htop showing the process is not killed by OOM)?

    • Could it be a problem with the specific SimNIBS mesh (e.g., non-convex geometry, air cavities, or holes) that causes the AMG solver to fail to converge or enter an infinite loop?

  2. How can I diagnose the stall further? Are there any additional debug flags or logs I can enable to get more verbose output from the DUNEuro binary?

  3. Could this be related to the mesh resolution? Given the mesh has ~811k nodes, should I consider decimating or remeshing the SimNIBS output using the Iso2mesh tools within Brainstorm before running DUNEuro, as suggested in the FEM tutorial?

  4. Is there a known issue with DUNEuro and specific SimNIBS CHARM meshes on Linux servers? I noticed a similar discussion about the "Coarse solver did not converge" error with high-density meshes.

  5. Are there any recommendations for solver settings that could improve convergence for high-resolution FEM meshes?

Additional Info

  • htop screenshot: I have attached a screenshot showing the MATLAB process consuming ~100% CPU but stalled.

  • MATLAB version output: version command returns: R2022b Update 7 (9.13.0.2399474) 64-bit

Thank you in advance for your help! Any guidance on how to resolve this stall or further diagnose the issue would be greatly appreciated.

2

Ping @tmedani

3

Hi @324

Sorry for the delayed response, and thanks for the detailed report.

It looks like you've taken many of the right steps to diagnose the issue. Based on what you've shared, my guess is that either the mesh is too large for your machine to handle, or there is another issue that isn't apparent from the information you've provided.

We are currently working on releasing a more stable version of DN using containers, and we expect that many of these technical issues will be resolved in that version.

In the meantime, I'd like to ask you to try one more test. Please run an FEM model using the simplified version you mentioned. Specifically, take the same BEM surface that worked successfully with OpenMEEG, generate an FEM mesh using the Iso2Mesh tool, and then run DN with that mesh. Let us know what results you get.

Hopefully, this will help us determine whether the issue is related to the mesh generation process or something else.

A+