Appion

Neil,

I am going to work on this this week. First thing I found is your change in r17701. The comment in line 82 to line 84 defines a as the major axis of the ellipse, alpha is measure from x-axis to a (major axis. Then in r17701, you reverse axis when a > b, which makes alpha measured from x-axis to minor axis.

What is it really?

I've made the sign changes in my sandbox and created a separate aptest database to test the ctfchallenge dataset 1. Amber ran ace, ace2,ctffind, phasor, and ctfRefine on them last week.

I looked at them today. Apart from ctfRefine, all the other seems to give the expected sign in the result plot, myamiweb, and database. I fixed the bug regarding ctfRefine and re-ran ctfRefine6 which gave similar results as others. The best image to look at is

zz13jul08z-ctfchal_set1_set_001_challenge_mic_006.mrc

It has a visually detectable astigmatism at -58 degrees.

makestack2.py result was checked with --fliptype=ace2image and --keepall. Keepall flag leaves the ctf-corrected image undeleted when the run is finished. Therefore, I could calculate from it the power spectrum and examine the astg_angle applied in the correction. It looks good, too (-58)

The use of astig_angle in apFrealign.py was checked by preparing single model reconstruction for Frealign and examining its parameter files. It looks good, too (-58).

Also checked parameter output for stack in myamiweb such as

/myamiweb/processing/listCTFvalues.php?expId=11956&sId=5

Remaining tasks:

1. Is there anything need changing for ctftilt? Neil?
2. Selection of bestCtfValue. Is it consistent with the display in image viewer? Amber?
3. Write dbschema update script. Anchi
4. Do we have xmipp result? Amber?

r17982 changes all the signes
r17983 is the schema update related files for this change.

scan-ctfdata.py can be used to find if a user is still adding ctf values to the database or using the table within 1 day, so that its update need to be delayed.

Database must be updated if appion python/php codes are updated.