Can't change classification uncertainty in live 2D jobs without error

[tlevitz]

Hi,

We are using v5.0.4 and have found that if we change the initial classification uncertainty factor from 2 we get an error. Any other fields seem to be able to be changed normally. Is this expected behavior?

Here is the error I just got:

When I changed just the classification uncertainty factor back to 2, the job runs fine.

Thanks!

[wtempel]

Thanks @tlevitz for this report. For analysis, please can you email us the job reports, available via the workspace associated with the Live session,

of

1. job P639.J6
2. the parent job of J6 that provided the Resume templates input for J6.

[tlevitz]

oh! that it is trying to resume templates is definitely the problem here. this is from a live session that did not use template picking, but the original session that the live profile was generated on did use template picking at some point I think. I assumed the only holdover from that is that it carries over the mask size (which is annoying, but we work around it) since the templates never show up and the blob picker is the one that defaults. But perhaps somewhere deep in there it is looking for templates that don’t exist?

Here is the picking screen from the live session:

Template picking is off:

2D classification just shows the mask diameter from whatever job the profile carried over from but nothing else (I changed the 100 classes manually, ignore that)

Live profile seems normal for blobs and not templates:

I’m not sure if this is now a different issue – I can send you the logs from P639J6 if you still need, but I actually don’t even know what the parent job is that provided the resume templates input, because it definitely isn’t in this project.

Now that I know what happened I can probably fix the issue by creating a new Live profile from scratch; I’ll test that out and ensure that the issue goes away.

[wtempel]

Thanks for the update @tlevitz.
In this case, please can you send us the details of the session profile that was used for the problematic session, which can be dumped into a file with this command

cd $(mktemp -d)
pwd # note path for file retrieval
cryosparcm cli "db.session_config_profiles.find_one({'title': 'name of config profile'})" > config_profile.txt

To dump the correct profile, please specify the relevant profile title in the command above.

Background and a potential workaround: A logic inside CryoSPARC Live controls whether 2D classification should be resumed or started “from scratch” when a new streaming Class 2D job is launched. It seems that this logic has failed in your case to prevent the resumption of 2D classification when the logic should instead, due to an incompatible change of input box size, have forced a start from scratch. The connection to the non-default Initial classification uncertainty factor is a coincidence: Changing the value back to the default may have triggered a start of classification “from scratch”.

We plan to improve the logic. In the mean time, you may try this workaround to force a start “from scratch”:

1. In the Live UI’s Configure Streaming Classification section, change the Classes input field to a number that differs from the previous classification run
   

   

2. Push the purple Build a new job with custom parameters button and change the Number of 2D classes, and any other parameter, including, if desired, Initial classification uncertainty factor, to the desired value.

3. Queue the job.

Please let us know if this workaround allows you to run streaming classification with a non-default Initial classification uncertainty factor.

[tlevitz]

Thank you, that makes sense! We’re having some unrelated cluster issues currently, but I will try the workaround later today.

For the profile named “Tundra_110k_UseMe” the output is -

{"_id": "69c588ae26904d8502b810c5", "updated_at":
"2026-04-23T13:43:45.287000", "created_at": "2026-03-26T19:27:42.334000",
"title": "Tundra_110k_UseMe", "created_by_user_id":
"65a6d42b3cbefe33fcf5c15c", "last_applied_at": "2026-04-23T1
3:43:45.287000", "compute_resources": {"phase_one_lane": "dfci-cluster",
"phase_one_gpus": 2, "phase_two_lane": "dfci-cluster", "phase_two_gpus": 2,
"phase_two_ssd": true, "auxiliary_lane": "dfci-cluster", "auxiliary_gpus":
1, "auxiliar
y_ssd": true, "priority": 0, "phase_one_workers_per_gpu": 1}, "exp_groups":
[], "session_params": {"gainref_flip_x": false, "gainref_flip_y": false,
"gainref_rotate_num": 0, "psize_A": 1.2, "accel_kv": 100.0, "cs_mm": 1.6,
"total_dose_e
_per_A2": 30.0, "phase_plate": false, "neg_stain": false,
"eer_upsampfactor": 2, "eer_numfractions": 40, "motion_res_max_align": 5.0,
"bfactor": 500.0, "frame_start": 0, "output_fcrop_factor": 1.0,
"variable_dose": false, "smooth_lambda
_cal": 0.5, "optimize_for_gpu_memory": false, "output_f16": true,
"blob_diameter_min": 80.0, "blob_diameter_max": 150.0, "use_circle": true,
"use_ellipse": false, "use_ring": false, "blob_lowpass_res_template": 20.0,
"blob_lowpass_res":
20.0, "blob_min_distance": 1.0, "blob_max_num_hits": 4000,
"thresh_score_min": 0.3, "box_size_pix": 256, "extract_f16": true},
"run_configuration": {"exposure_processing_priority": "normal",
"phase_one_wait_for_exposures": false, "auto
_pause": "graceful", "auto_pause_after_idle_minutes": 30}}

I don’t think it’s related, but auto-pause also never triggers for this preset. We come in the next morning (often 12+ hours since the last exposure of a 1000 movie dataset) and it is still waiting.

[tlevitz]

Okay, some further investigation of the issue. Overall finding: the issue is how I indicate the new number of classes, classification uncertainty is a red herring (although now I am getting a different error than before). It does seem to be an issue of whether the job auto-starts from scratch again or not.

1. I started a streaming 2D job with default parameters (50 classes, uncertainty 2) and let it go until the “waiting” stage

2. I stopped the 2D job and built a new one with 100 classes and uncertainty 5, but indicated 100 classes just in the normal parameters area after hitting the blue hammer button. This triggered an assertion error (see below)

3. The GUI reverted uncertainty to 2 but kept 100 classes. When I ran this new streaming 2D job, it started from scratch and ran fine. I let this run until the “waiting” stage.

4. I stopped that 2D job and built a new one with 150 classes and uncertainty 5, but this time indicated 150 classes in the larger “Classes” option up top (the way you indicated in step 2). This worked fine.

5. For speed purposes I started a new job with 10 classes. This also worked fine and I let it run until the waiting phase.

6. I started a new job with 15 classes but changed the number of classes in the “normal” part of the UI instead of the specific classes parameter up top (although this changes itself when you change the one below). This triggered the assertion error again, even without changing classification uncertainty.

7. I started another job with the same parameters and it ran fine. I let this run to the waiting stage.

8. I started a new job with 20 classes but changed the number of classes in the part of the UI that you indicated in step 2. This worked fine.

9. Started a new job with 25 classes, changed it via the part of the UI you indicated, also changed classification uncertainty to 5. This was fine.

10. Started a new job with 30 classes and uncertainty 5, changed it via the smaller part of the GUI, this triggered the assertion error.

    This is the “smaller part of the GUI”

    

    This is the “part of the GUI you indicated in step 2”

    

    This is the assertion error

    

[fhu]

Hi @tlevitz thank you for reporting, we’re working on a fix for this.