****ERROR**** particle not normalized

Submitted by jackmao on Fri, 2010-08-13 20:19

Forums

Frealign

Hi Niko,

I got this error message when reading the spider stack file:

............................

Opening SPIDER file for READ...
File : /home/spider/CryoEM_Software/Frealign/frealign_v8.09/examples/refinetest/../ENV06test_norm.spi
Non-native byte order
NX, NY, NZ: 200 200 1157
MODE : real
Min, max : 0.000000 0.000000
Mean, RMS : 0.000000 0.000000
TITLE 1:
TITLE 2:
TITLE 3: CREATED 13-AUG-2010 AT 18:22:39

Time before particle 1 was 18:25:22
****ERROR**** particle not normalized, N = 1
Fatal error

I am sure that all those particle images in the stack has an zero average, but the scale is not normalized. I read the codes in lmain.f that give rise
to this error message, yet still cannot figure out why PMAX and PMIN were wrong. Any help and suggestions?

Plus, before this error message, I got a warning like:

............................................................
Opening SPIDER file for READ...
File : ENV06test_2.spi_1_200
Non-native byte order
NX, NY, NZ: 200 200 200
MODE : real
Min, max : -0.7605414 5.512888
Mean, RMS : 0.5032382E-01 0.2408888
TITLE 1:
TITLE 2:
TITLE 3: CREATED 04-AUG-2010 AT 00:15:03

***WARNING*** Particle mask exceeds window size!
***WARNING*** Circumference STD
significant compared with volume STD, could indicate
noisy reference or density gradient !!!
.............................................................

I am not sure these two events are associated. I am still trying a few other options to diagnose the problem, but so far has been caught by the above fatal error. I appreciate any help and advice to go through this.

Questions:
(1) How does Frealign define particle normalization?
(2) How does Frealign determine particle mask?

Thanks

niko Sat, 2010-08-14 11:44

I looked at your error message and the only thing that Frealign checks is that an image contains a minimum density below zero and a maximum density above zero. This should be the case if you normalized your particles to have an average of zero.

If you are sure about your particle images being normalized, maybe there is a problem reading the Spider files. Would you be able to convert your data from Spider to CCP4/MRC? Of all the formats implemented in Frealign, the CCP4/MRC format is probably the most stable. You can use the program em2em for this (but make sure you answer 'No' when it asks you 'Consider different coordinate systems'). If the error persists, check the image with a display program.

The warning about the particle mask exceeding the window size can be ignored. Presumably, you entered a value for 'RO' that takes the edge of your mask beyond the edge of your image box. Frealign uses a soft edge for the mask and, therefore, 3 pixels are always added towards RO. So even if your mask radius RO would not exceed (half) the box size, if it is close it might still exceed it after smoothing the edge.

The warning about the circumference standard deviation can probably also be ignored. However, it is unusual to have a significant STD at the edge of your reference volume, unless it is very noisy. So it is possible that this warning is related to your normalization error if there is indeed a problem with reading your Spider files (in which case the read-in densities might be wrong and you get a significant STD at the edge of your reference volume). Again, try converting your data to CCP4/MRC.

A word about the MRC format: This should now be the same as the CCP4 format. It used to be a little different. em2em will output the new MRC format but other programs might not. To be sure, just convert to CCP4 instead.

jackmao Sat, 2010-08-14 14:57

Hi Niko,

Thank you so much for quick response and help in diagnosis of the problem. I totally agree with you analysis. I recently switch to SPIDER 18.10 from 17.**. I found some old SPIDER scripts have problem to be executed by this version. I did tried to convert the images to CCP4, but it was done by SPIDER command 'CP TO CCP4'. But if the new version of SPIDER has problem with its own format, this may affect its own transform program. I did ignore that I should try it again with em2em. Many thanks for mentioning this point.

Thanks again,
Jack