Error in Local Refinement

Local Refinement
1

Why does it suddenly stop after running for a while when I enable Non-uniform refine enable while running Local Refinement with default values, with no error message? The bottom of the log shows:

Non-uniform regularization with compute option: GPU
Running local cross validation for A …
====== Job process terminated abnormally.

2

@hand The large (?) box size of the particles may have caused the job to run out ouf RAM. What are the

  • box size?
  • final lines of the job log (under Metadata|Log)?
  • amount of RAM on the worker where the job ran or, in case of the cluster job, the amount of RAM allocated to the job?
3

Thank you for your suggestion.

Here is my system information:

        box size: 448
        Eventlog：Non-uniform regularization with compute option: GPU
                  Running local cross validation for A …
                  ====== Job process terminated abnormally.
        Metadatalog: main process now complete at 2026-04-17 11:27:20.644164
                     monitor process now complete at 2026-04-17 11:27:21.203514
        RAM:total 31Gi

Additionally, my samples consist of rod-like proteins like microtubules, with flexible proteins attached to their outer surfaces. Therefore, I’m using a box size of 448. Will enabling the “Non-uniform refine” option have any significant impact on my results?

4

@hand You marked Error in Local Refinement - #3 by hand as “Solution”. Does this mean you no longer require help regarding the abnormal process termination? If you still need help, please post additional (10 - 20) lines from Metadata|Log that precede process now complete lines. Also let us know whether the worker where local refinement ran was part of cluster-type, such as slurm, scheduler lane.

5

This job was run on a local workstation (not a cluster or SLURM environment).

Metadatalog:

========= sending heartbeat at 2026-04-17 11:23:38.867329
========= sending heartbeat at 2026-04-17 11:23:48.881245
========= sending heartbeat at 2026-04-17 11:23:58.899937
========= sending heartbeat at 2026-04-17 11:24:08.913960
========= sending heartbeat at 2026-04-17 11:24:18.932599
========= sending heartbeat at 2026-04-17 11:24:28.945787
========= sending heartbeat at 2026-04-17 11:24:38.961123
========= sending heartbeat at 2026-04-17 11:24:48.974306
========= sending heartbeat at 2026-04-17 11:24:58.988689
========= sending heartbeat at 2026-04-17 11:25:09.001880
========= sending heartbeat at 2026-04-17 11:25:19.012245
========= sending heartbeat at 2026-04-17 11:25:29.026653
========= sending heartbeat at 2026-04-17 11:25:39.035705
========= sending heartbeat at 2026-04-17 11:25:49.044197
========= sending heartbeat at 2026-04-17 11:25:59.057090
========= sending heartbeat at 2026-04-17 11:26:09.071317
========= sending heartbeat at 2026-04-17 11:26:19.077752
========= sending heartbeat at 2026-04-17 11:26:29.099982
========= sending heartbeat at 2026-04-17 11:26:39.119700
========= sending heartbeat at 2026-04-17 11:26:49.134480
========= main process now complete at 2026-04-17 11:27:20.644164.
========= monitor process now complete at 2026-04-17 11:27:21.203514.

6

indicates a lower-level “exception”. The OS or kernel logs of the worker node (workstation in your case), accessible via commands like dmesg or
journalctl -k, may have more information. You may use grep to filter these commands’ output using the numeric process IDs of the job processes. For example (hypothetical process ID 267341)

# on worker
sudo journalctl -k | grep 267341

Job-related process IDs are shown in the job log (Metadata | Log in the app) and can be displayed with a bash command like (on the CryoSPARC master node, in your case also the workstation):

# on master
# replace P99, J199 with actual project and job IDs
cryosparcm joblog P99 J199 | grep -i " pid "

In the current case, it is likely that the job ran out of RAM.

is on the low end of minimum worker requirements.