Bug #1524
closedapplyctf from EMAN 1.9 release causes strip in the corrected image when installed on CentOS 6
0%
Description
unknown error. It looks like this
from a command like this:
applyctf /ami/data00/leginon/12jan12z/rawdata/12jan12z_06jul12a_00015gr_00028sq_00004hl_00002en.mrc out-ctfcorrect.mrc parm=-2.594319,200,1,0.159,0,17.4,9,1.53,120,2.0,1.000000 setparm flipphase
I reported it to EMAN team and was advised to try the daily build. The 2012-Jan-15 build worked.
Regarding bug fix of the release, here is the reply from Grant Tang <gtang@bcm.edu>
You can use EMAN daily release safely because we do not do much development for EMAN1 unless important bu fix. Grant >On Tue, 2012-01-17 at 12:56 -0600, Anchi Cheng wrote: >Please let me know when this bug fix makes >it into the release so that we can re-direct people to install >that instead.
To do: replace Appion redmine attachment to the daily build.
Files
Updated by Anchi Cheng almost 13 years ago
more e-mail from Steve Ludtke
Hi Anchi. EMAN1 hasn't been actively developed for ~5 years, and has been formally deprecated for ~1 year now. We continue to update the nightly snapshots, and occasionally fix small bugs (or tweak File I/O), but don't plan on any more formal EMAN1 releases.
Updated by Anchi Cheng almost 13 years ago
Sargis,
Please try compiling EMAN1 daily build on CentOS 6 to see if the problem can be solved. EMAN1 needs fftw2 while we use fftw3 in Appion python code, so be aware of possible comflict.
However, Steve Lukte said it would not be a problem as they would carry different names.
Updated by Sargis Dallakyan almost 13 years ago
- Assignee changed from Amber Herold to Sargis Dallakyan
Updated by Anchi Cheng almost 13 years ago
We have artifact problem on proc2d for simple manipulation like shrink as well. This is bad.
Updated by Sargis Dallakyan almost 13 years ago
- Status changed from Assigned to Won't Fix or Won't Do
Thank you Anchi. I installed EMAN1 (1.9) from source (including fftw2) on 64-bit CentOS 6. This problems is still there. 32-bit binaries work fine on 64-bit CentOS 6. Will use pre-compiled 32-bit binaries for EMAN1 for now.
Updated by Anchi Cheng almost 13 years ago
E-mail from EMAN team member Grant Tang (We have CentOS 6.2):
Hi, Anchi:
Your test case is very precious to track this problem down. This artifact problem does not show up on the computer I used to produce EMAN 64 bit binary. I also tested to install this binary on more than a dozen of different Linux system. It looks like most possibly this is due to a bug in the some version of gcc library, libstdc++ to be specifically.
Two versions of Linux system can reproduce this issue:- Fedora 14 x86_64, gcc version 4.5.1-4.fc14
- CentOS 6.2 x86_64, gcc version 4.4.6-3.el6
And this problem is limited to redhat/fedora/centos system only. For example, The OpenSuSE 11.04 has gcc 4.5.1 but does not have this problem.
When you say the problem is on CentOS6. I guess you already updated your system to CentOS6.2 since this issue does not show up on CentOS6 (I did not test it on 6.1).
My suggestion would be to avoid using EMAN1 on 64bit Fedora14 and CentOS6.2 system.
Grant
Updated by Anchi Cheng almost 13 years ago
- File start.hed start.hed added
- File start.img start.img added
- File lp.hed lp.hed added
- File lp.img lp.img added
Here is the test case I sent him:
It turns out that we get artifact in low pass filtering with proc2d as well, so the test case used this command:
proc2d start.hed lp.hed apix=1.64 lp=10
Updated by Neil Voss over 12 years ago
I tried Anchi's test on 3 of my computers running both CentOS 6.2 and Fedora 16 on both Intel and Athlon machines, no artifacts.
Link to image:
https://emportal.scripps.edu/myami/imgreport.php?id=1770361&preset=all
Updated by Neil Voss over 12 years ago
no artifacts in the CTF correction either.
Updated by Neil Voss over 12 years ago
Fedora 16:
ldd /data01/prog/eman1/bin/proc2d
linux-vdso.so.1 => (0x00007fff7dbff000)
libEM.so => /usr/local/EMAN/lib/libEM.so (0x00007f3674443000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e1ba00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003e16a00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e17600000)
libc.so.6 => /lib64/libc.so.6 (0x0000003e15e00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003e15a00000)
Updated by Anchi Cheng over 12 years ago
- Status changed from Won't Fix or Won't Do to Assigned
- Target version changed from Appion/Leginon 2.2.0 to Appion/Leginon 3.0.0
Sargis,
Could you give it a try again. If it still does not work on your test machine, please find out from Neil what is needed so that we will have a working version when guppy moves to CentOS 6.2. We still have too many functions that depends on EMAN1
Updated by Anchi Cheng over 12 years ago
see update from Neil on Issue #1757 for more details
Updated by Sargis Dallakyan over 12 years ago
Thank you Anchi and Neil. I run the latest nightly EMAN 1.9 ($Date: 2012/04/23 17:01:03 $) and the artifact problem no longer shows up. I'm currently using the same version of CentOS as Neil is using (CentOS 6.2 x86_64, gcc version 4.4.6-3.el6).
$ ldd /opt/EMAN/bin/proc2d
linux-vdso.so.1 => (0x00007fffc0fff000)
libEM.so => /opt/EMAN/lib/libEM.so (0x00007f7b9928b000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003d17600000)
libm.so.6 => /lib64/libm.so.6 (0x0000003d10e00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003d17200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d11200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d10a00000)
Updated by Anonymous over 12 years ago
So the good news: the x86_64 cluster binaries of proc2d worked for me on Ubuntu 12.04 on some old '08 Xeons and newer '12 Xeons. At least they do with Anchi's test case.
The bad news is: I only found this out after saying "screw it" while trying to get EMAN compiled from source on Ubuntu 12.04. I was having problems linking to newer versions of Python and Qt, etc. With enough work someone could get it to work probably, but...
Updated by Neil Voss over 12 years ago
Craig, I highly recommend using the "nightly build" source code checkout. It fixes a lot of the newer software conflicts.
Updated by Anchi Cheng over 12 years ago
- Status changed from Assigned to Merge
Sargis helped me to do yum update on the 3.0 developing laptop. After that, the nightly-built works there, too. Looks like we can close this issue now.
Updated by Amber Herold over 11 years ago
- Status changed from Merge to Closed
- Affected Version changed from Appion/Leginon 2.2.0 (trunk) to Appion/Leginon 2.2.0