Appion

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.

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.

We have artifact problem on proc2d for simple manipulation like shrink as well. This is bad.

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.

• 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

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

no artifacts in the CTF correction either.

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)

see update from Neil on Issue #1757 for more details

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)

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...

Craig, I highly recommend using the "nightly build" source code checkout. It fixes a lot of the newer software conflicts.