Bug #3960
openCTF estimation resmax parameter get modified in a run mixed with and without bestctf
0%
Description
For example, If we have two images in the session, the first image image1.mrc has a successful previous ctf run, image2.mrc failed in previous run, then --bestctf causes the following problem.
This part of ctffind4.py code redefined self.params['resmax'] while running image1.mrc
if gmean < self.params['resmin']*0.9:
# replace only if valid Issue #3291
self.params['resmax'] = round(gmean,2)
apDisplay.printColor("Setting resmax to the geometric mean of resolution values", "purple")
Therefore, when image2.mrc is processed, resmax is at lower resolution than the original user definition.
This problem get worse next time a bestctf is found. Making resmax become lower and lower.
This bug is in at lease ctffind4.py and ctfestimate.py
attached is a pair of image that if you upload alternatively, you may get the error of ctffin4 floating point divide by zero in ctffin4
pixelsize 2.816 A
ht 200 kV
cs 2.0 mm
Use myamiweb defaults.
Files
Updated by Anchi Cheng almost 9 years ago
- Related to Bug #3906: CTF estimation resmax parameter get modified in a run mixed with and without bestctf added
Updated by Neil Voss almost 9 years ago
- Assignee changed from Neil Voss to Anchi Cheng
Is this myami-3.2? Because in the trunk I have this:
if ctfvalue is not None and self.params['bestdb'] is True:
### set res max from resolution_80_percent
gmean = (ctfvalue['resolution_80_percent']*ctfvalue['resolution_50_percent']*self.params['resmax'])**(1/3.)
if gmean < self.params['resmin']*0.9:
# replace only if valid Issue #3291
self.params['resmax'] = round(gmean,2)
apDisplay.printColor("Setting resmax to the geometric mean of resolution values", "purple")
which would only run in bestdb is True
Updated by Neil Voss almost 9 years ago
I had it reduce the resmax, because maybe it was failing because too much information was included or the CTF rings fade away. Resolution and ResMax is calculated on an image by image basis, instead of being fixed by the user. But the user does have input in the calculation.
say image resolutions are 15A and 10A, user inputs 5A
gmean = (15*10*5)**(1/3.) = 9.08A
user inputs 10A
gmean = (15*10*10)**(1/3.) = 11.44A
say image resolutions are 7A and 5A, user inputs 5A
gmean = (15*10*5)**(1/3.) = 5.59A
user inputs 10A
gmean = (15*10*10)**(1/3.) = 7.04A
We run a second time,
- if the fit improves, the resolution improves, and resmax goes out further
- if the fit is worse, the resolution stays the same, and resmax stays the same
I do not think this case would occur: "This problem get worse next time a bestctf is found. Making resmax become lower and lower."
Updated by Anchi Cheng almost 9 years ago
Actually, it has already happened. That's how I discover this.
The thing is , self.params get modified by the first image which has gmean worse than 10A because the fit only barely previously. When image2 is processed without previous value, it used self.params value that is no longer user defined.
To solve this, the original resmax has to be saved through appionLoop and used as default when there is no previous bestctf for a particular image
Updated by Anchi Cheng almost 9 years ago
- Assignee changed from Anchi Cheng to Neil Voss
According to your example,
self.params['resmax'] changed from 5 Å to 9.08 Å on image 1 because
self.params['resmin'] is 50 Å and 0.9 of that is 45 Å.
Appion loop reaches the second image, which happened to fail in previous run, so there is no bestctf image resolution, it has to get resmax from self.params. As a result, it disregard user's original request. I don't think that it what you intended. I may be wrong, but I think you only meant to change resmax for the same image when you rerun in another estimation run or in your refinement.
Updated by Neil Voss almost 9 years ago
Oh, I did not see that it was overwriting the user-supplied value. That is a bug.
I will have time tomorrow to fix it. This would affect both CTFFIND3 and CTFFIND4.
Updated by Neil Voss almost 9 years ago
- Status changed from Assigned to In Code Review
- Assignee changed from Neil Voss to Anchi Cheng
created a new local variable for resmax
Updated by Neil Voss almost 9 years ago
- Related to Bug #3491: ctffind4.py resmax larger than resmin added