Question re: input with regards to Reference Based Motion Correction

Motion Correction
1

Hi all,

I have been processing a dataset and am trying to run a final polishing step. Upon reference based motion correction, I received an error referencing EER frames (attaching error messages below), but this data was not collected in an .EER format. Is this the normal expected output for reference based motion correction?

Upon looking back at the import job, I realized I did not remove/change the value for EER number of fractions from the default value40, since I figured it was not necessary to change because my data was in .tif format. Do I need to redo import and subsequent jobs with this variable turned off to get reference based motion correction to work best or does the import ignore the EER number of fractions value if the data is not in .EER format?

Thank you for any help you can provide.

Best,
John

Error message:

Traceback (most recent call last):
File “/lustre/fs4/alus_lab/scratch/alus_csparc/node246CryosparcWorker/cryosparc_worker/cryosparc_compute/jobs/runcommon.py”, line 2306, in run_with_except_hook
run_old(*args, **kw)
File “cryosparc_master/cryosparc_compute/gpu/gpucore.py”, line 136, in cryosparc_master.cryosparc_compute.gpu.gpucore.GPUThread.run
File “cryosparc_master/cryosparc_compute/gpu/gpucore.py”, line 137, in cryosparc_master.cryosparc_compute.gpu.gpucore.GPUThread.run
File “cryosparc_master/cryosparc_compute/engine/engine.py”, line 1090, in cryosparc_master.cryosparc_compute.engine.engine.process.work
File “cryosparc_master/cryosparc_compute/engine/engine.py”, line 138, in cryosparc_master.cryosparc_compute.engine.engine.EngineThread.load_image_data_gpu
File “/lustre/fs4/alus_lab/scratch/alus_csparc/node246CryosparcWorker/cryosparc_worker/cryosparc_compute/ioengine/cmdbuf.py”, line 87, in wait
raise IOError(‘\n\n’.join(errs))
OSError: I/O error, mrc_readmic (1) line 977: Invalid argument
The requested frame/particle cannot be accessed. The file may be corrupt, or there may be a mismatch between the file and its associated metadata (i.e. cryosparc .cs file).

I/O request details:
filename: /tmp/cryosparcSSD/instance_node246.hpc.rockefeller.internal:61001/links/P2-J760-1750739603/7698a5b2270c2f6e22256f0cf199b685b8a1060a.mrc
data type: 0x10
frames: [855:856]
eer upsample factor: 2
eer number of fractions: 40

I/O error, mrc_readmic (1) line 977: Invalid argument
The requested frame/particle cannot be accessed. The file may be corrupt, or there may be a mismatch between the file and its associated metadata (i.e. cryosparc .cs file).

I/O request details:
filename: /tmp/cryosparcSSD/instance_node246.hpc.rockefeller.internal:61001/links/P2-J760-1750739603/7698a5b2270c2f6e22256f0cf199b685b8a1060a.mrc
data type: 0x10
frames: [462:463]
eer upsample factor: 2
eer number of fractions: 40

I/O error, mrc_readmic (1) line 977: Invalid argument
The requested frame/particle cannot be accessed. The file may be corrupt, or there may be a mismatch between the file and its associated metadata (i.e. cryosparc .cs file).

I/O request details:
filename: /tmp/cryosparcSSD/instance_node246.hpc.rockefeller.internal:61001/links/P2-J760-1750739603/958aef14fed673c47efabd1d9382ab1deb8493d9.mrc
data type: 0x10
frames: [499:500]
eer upsample factor: 2
eer number of fractions: 40

I/O error, mrc_readmic (1) line 977: Invalid argument
The requested frame/particle cannot be accessed. The file may be corrupt, or there may be a mismatch between the file and its associated metadata (i.e. cryosparc .cs file).

I/O request details:
filename: /tmp/cryosparcSSD/instance_node246.hpc.rockefeller.internal:61001/links/P2-J760-1750739603/958aef14fed673c47efabd1d9382ab1deb8493d9.mrc
data type: 0x10
frames: [560:561]
eer upsample factor: 2
eer number of fractions: 40

2

The EER error is a bit misleading, because since support for EER was added, regardless of format CryoSPARC writes the upsampling and frame split information (MRC, MRCS and TIFF all output the same in the error if, for example, the mount point of the movies is missing). The error is pointing to .mrc files which appear to be located on a /tmp/ mount? Since /tmp/ is (generally) RAMFS which gets cleared as the system needs (and/or the system gets rebooted), my first question would be whether the servers have been rebooted since you last accessed the micrographs.

Otherwise, check the symlinks for the movies, that they are still good, that the mount point for the raw data is still present, and that any NFS shares are not stale (a cause for stale NFS shares would be the data server losing network briefly, or being rebooted without the server having the share unmounted/remounted…)