Leginon

Tomography node requests transformed target more than once so your description is not explicit enough for me. Most likely there is an exception that we did not catch for the logger. Please check the text terminal where Leginon is started on the linux box. Also it will help me if you take screenshot of the problem nodes so that I can find from the logs where exactly it got stuck.

Thanks.

The following error I cannot figure out. Why is it using two different sized images?

Traceback (most recent call last):
File "/usr/lib64/python2.6/threading.py", line 522, in _bootstrap_inner
self.run()
File "/usr/lib64/python2.6/threading.py", line 477, in run
self._target(*self.__args, **self.__kwargs)
File "/usr/local/lib64/python2.6/site-packages/leginon/databinder.py", line 131, in handleData
method(args)
File "/usr/local/lib64/python2.6/site-packages/leginon/transformmanager.py", line 449, in handleTransformTargetEvent
newtarget = self.transformTarget(oldtarget, level)
File "/usr/local/lib64/python2.6/site-packages/leginon/transformmanager.py", line 233, in transformTarget
matrix = self.calculateMatrix(parentimage, newparentimage)
File "/usr/local/lib64/python2.6/site-packages/leginon/transformmanager.py", line 170, in calculateMatrix
matrix = reg.registerImageData(image1,image2)
File "/usr/local/lib64/python2.6/site-packages/leginon/transformmanager.py", line 78, in registerImageData
matrix = self.register(array1, array2)
File "/usr/local/lib64/python2.6/site-packages/leginon/transformmanager.py", line 100, in register
corrimage = self.correlator.phaseCorrelate()
File "/usr/local/lib64/python2.6/site-packages/pyami/correlator.py", line 126, in phaseCorrelate
self.crossCorrelationFFT()
File "/usr/local/lib64/python2.6/site-packages/pyami/correlator.py", line 88, in crossCorrelationFFT
raise RuntimeError('images not same dimensions')
RuntimeError: images not same dimensions

Yes, it found that the original image where the tomography target is picked from (likely hl) has changed dimension when it needs to reaquire it during the tomography data collection. Was the preset dimension changed? If not, one of them might be recorded in the database wrongly. Usually it is wrong because the camera or tem was not picked.

There was a bug #770 fixed before 2.0 release that is related to your error but should not have shown up any more even if you did use simulated target to start the sequence.

Try start a new session and check the preset camera/tem used before you import to that session and see if it resolves itself. If not, we might need a mysqldump from your database to figure this one out.

Restarted everything. Now it is hanging at the target adj node. Please see image.

well. after a couple of restarts and a missing beam shift calibration I am collecting tilt series again. I still don't know why the program hangs sometimes.
Thanks,
Cheri

Could you ask Harry to send me your database dump? I want to study it. Maybe I will be able figure out. It shouldn't not be unpredictable like this.

By the way, I don't see anything in the logger in target-adj.tiff

Cheri,

Looking at the database Harry sent me, I found two abnormalities:

11jun02a: 11jun02a_vecad-gr5_00010gr_00007sq_v01_00006hl.mrc is recorded in the database as having 29000x and 1kx1k binned by 4 camrea dimension. This is the value of the "preview" preset taken right before this image. You can see this from the web imageviewer.

11jun03a: 11jun03a_xj11gr3_00045gr_00037sq_v01_00001hl_v02_00002tomo_001.mrc is recorded to have the scope and camera parameters of "sq" preset.

I was not able to find evidence of what went wrong exactly in the second case, but the first one did leave enough trace. It seems that you selected and submitted a preview target while the scope was busy acquiring 0006hl image. In order to allow queuing of any order, Leginon does not prevent different nodes from talking to the microscope and camera. As a result, when queuing is used and wait for a node to processing the target is off, as people like to do to save time, two nodes can try to ask the scope to set to its required preset and ask the camera to take picture at the same time. It is dangerous, because a node make be getting an image from the scope while the other is in process of changing the mag. This can either means that the image recorded is at the wrong magnification, or, if the timing is slightly off, the image is correctly saved but the database record, which was retrieved from the scope a fraction of a second later, is saved to a wrong value. You probably had the second case if the image looked normal from your end.

It is most likely you had another conflict of scope usage by two nodes on 11jun03a, although I could not be sure.

At the moment we don't have a software solution that can prevent this without removing the popular queuing flexability. My suggestion to you is to remind yourself that THERE IS ONLY ONE MICROSCOPE. Slow down a bit and check if any other node is still using the scope (turning wheel) before submitting targets. Unlike other types of targets, preview targets get processed immediately even without submitting the whole queue, so be careful with it. If you are eager to preview a perfect target but Leginon is still acquiring other holes, use the pause button in "Hole" node so that it can wait for you. In case of new users, you can change the settings of the acquisition nodes upstream of the queuing target finder to wait for target to be processed which will pause the scope usage until you finish submitting the targets on the acquired image.