Error during non uniform refinement: TypeError

Troubleshooting
1

Hi,

I am seeing this error in non uniform refinement (v3.2, latest patch) after the fourth iteration - I’ve never seen it before but it happened on a bunch of related jobs - thoughts? Refinement looked normal otherwise…

Screenshot of of input parameters and error below - I have run other refinement jobs with these parameters without any errors.

The job that I cloned these from had the Number of final passes parameter set - and all the jobs that failed seem to be failing just before convergence (they all died in the first iteration after the full dataset had been seen). Could it be that it is still running some check as to whether the number of final passes has been satisfied, and failing because this is set to None rather than a number?

Cheers
Oli

image
image2418×1634 461 KB

[CPU: 39.51 GB]    Minimizing over per-particle scale factor
[CPU: 39.51 GB]  -- THR 0 BATCH 500 NUM 7145 TOTAL 121.24235 ELAPSED 498.55367 --
[CPU: 42.52 GB]    Processed 58579.000 images in 501.331s.
[CPU: 42.52 GB]    Rescaling optimal scales and reconstruction result to preserve median 1.0. Rescaling factor is 1.31340
[CPU: 42.52 GB]    Computing FSCs... 
[CPU: 42.64 GB]      Done in 294.235s
[CPU: 16.22 GB]  Traceback (most recent call last):
  File "cryosparc_worker/cryosparc_compute/run.py", line 84, in cryosparc_compute.run.main
  File "cryosparc_worker/cryosparc_compute/jobs/refine/newrun.py", line 628, in cryosparc_compute.jobs.refine.newrun.run_homo_refine
TypeError: '>' not supported between instances of 'NoneType' and 'int'```
2

Dear @olibclarke,

I think your suspicion is correct, the Number of final passes parameter is checked right after convergence is detected, and unfortunately the parameter isn’t checked for validity before that, so if its set to None (rather than the default of 0), then it would produce this error. If you clear and re-run the job with it set to an integer, it should hopefully avoid the error.

Best,
Michael

1 Like
3

Yes, I’m doing that now, thanks - would be good if it was checked at run time, particularly given a number of integer parameters do have a default of None