Appion

This is a somewhat odd bug that was noticed by Gabe Ozorowski. It can be most-easily demonstrated with the following data set in project 444 (RHoffman - testing) session 14jul28b. (Anyone that can't view that project/session that wants to, please email me. I've attached a graphic that should suffice.)

I ran the same CL2D calculation, once stopping at 32 classes, and once continuing to 256 classes. "Level 4" of the 256-class calculation also has 32 classes.

So the summary page for the 32-class calculation:

http://longboard.scripps.edu/gammamyamiweb/processing/viewstack.php?expId=13761&clusterId=15&file=/gpfs/group/em/appion/rmhoff/14jul28b/align/cl2d1/part14jul28o16_level_04_.hed

and for "level 4" of the 256-class calculation:

http://longboard.scripps.edu/gammamyamiweb/processing/viewstack.php?expId=13761&clusterId=20&file=/gpfs/group/em/appion/rmhoff/14jul28b/align/cl2d2/part14jul29r01_level_04_.hed


should have the same results (varying only in whatever random seeding is associated with a CL2D run.)

Indeed, the images displayed on those two links are nearly identical (see cl2dbug.png, attached.) But the single particles correctly correspond to the class average in the 32-class example (top part of figure, annotated with green arrows) and do not correctly correspond for the level-4-of-256-class example (bottom part of figure, annotated with red arrows.)

From looking at this yesterday, we think there's some reason to suspect that it isn't a problem with CL2D but with the post-processing required to generate these summaries.

It's a pernicious problem because the incorrectly-mapped single particles will also get transferred to any substacks. We've found this problem for any (Appion-bassed Xmipp2) CL2D calculation that gives more than 64 classes. Confirmation from Dmitry and any others watchers is desirable.