i386 and i686 (generally written as x86 by techs) are basically versions of the 32bit CPU architecture - i386 refers to the instruction set found in the Intel 386 series (386sx25, 386dx2-66, etc.), i686 refers to the enhanced instruction set starting with Pentium Pro (5 second overview, it's more complicated than that - hit up Wikipedia). Various other Linux distros have already dropped 32bit support (RHEL / CentOS 7 for example), it's been on it's way out for a long time.

Did not understand the CP answer, but earlier it was explained by one of the techs that it let's say, the weather/climate data analysis standard... measurements are offered of data points taken every 6 hours. Besides not looking for 1gig of data being intermediately stored in hopes the model can be reloaded without bites going the wrong way. Already my machine is sweating with limiting it by 1 at the time. Last upload took so long, there were 4 other tasks results backed up by the time the upload was finished.

An update to my last post - the previously mentioned beta-ARP WU is now at 65% after 25hrs (it's running on an 8 thread chip) with dozens of ordinary Openzika's and beta-SCC's passing it by and processing to successful conclusion in the meantime!! The prediction is for a further 13hrs of crunching time.... and that's on a 24/7 machine with 12GB of RAM...

I'm not sure that I would want more than one ARP WU running at a time...or am I being pessimistic about the potential resource requirements of these WU's?

I have RHEL6.10 running on a 64-bit machine. Therefore, I get mostly x86_64 programs to run. However my ClimatePrediction stuff is all x86 stuff (although x86_64 programs will be coming out in the future).

For WCG stuff, I have some programs still lying around and, as far as I know, they have all worked. Here are a few.

wcgrid_beta11_7.00_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
wcgrid_beta11_qchemB_prod_linux.x86.7.00: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
wcgrid_beta17_7.36_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, stripped
wcgrid_beta17_gfx_7.43_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
wcgrid_beta17_map_7.43_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, stripped
wcgrid_beta19_7.21_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, stripped

Note that the 32-bit ones were statically-linked, so it does not matter what libraries my machine has. It happens that I have the compatibility library for the C++ stuff, but it is not always used.

On the other hand, it appears that compatibility libraries are no longer required. Here is a ClimatePrediction example:

$ ldd hadam4_8.09_i686-pc-linux-gnu
linux-gate.so.1 => (0x00ba9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x007c3000)
libdl.so.2 => /lib/libdl.so.2 (0x007eb000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00c44000)
libm.so.6 => /lib/libm.so.6 (0x00aaf000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0013b000)
libc.so.6 => /lib/libc.so.6 (0x0062a000)
/lib/ld-linux.so.2 (0x56617000)

$ ls -l /usr/lib/libstdc++.so.6
Jun 19 2018 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.13
$ rpm -qf /usr/lib/libstdc++.so.6
libstdc++-4.4.7-23.el6.i686
$ rpm -qf /usr/lib/libstdc++.so.6.0.13
libstdc++-4.4.7-23.el6.i686

On my machine, the compatibility library is
$rpm -qf libstdc++-3-libc6.2-2-2.10.0.so
compat-libstdc++-296-2.96-144.el6.i686
And it does not seem to be needed anymore, at least for ClimatePrediction programs.

Would it be helpful to change the title of this thread to make it clear that this is for the ARP1 beta?