[JonW]

Hello fellow foamers

I recently bought my first arm unit, more specifically a very small desktop called "trim-slice pro". It has arm version 7 (more precisely the NVIDIA Tegra2 Dual Core Arm Cortex A9 1GH). After upgrading to Ubuntu 12.04 I quickly started to wonder if it was possible to compile OF 2.2.x (using git pull) on it.

before the compilation I did the following:
sudo ln -s /usr/bin/make /usr/bin/gmake
sudo ln -s /lib/arm-linux-gnueabihf/libz.so.1 /usr/lib/libz.so.1
sudo ln -s /lib/arm-linux-gnueabihf/libc.so.6 /lib/libc.so.6

I did the above because /usr/bin/gmake, /usr/lib/libz.so.1 and /lib/libc.so.6 did not exist.

After about 12 to 13 hours of compiling (using "export WM_NCOMPPROCS=2"), everything seemed fine. The only problems occurs if I try to compile paraview, which is not really important.

There are no errors (except for paraview) in my wmake log file. However, when I go to the tutorial cases, it is as the binaries do nothing (the binaries do exist!). For example, doing a blockMesh in the icoFoam example gives nothing. Also, foam2vtk gives nothing. Nothing happens when starting icoFoam. The same applies for the other tutorial cases like interFoam.

Have any of you had the same problem?

Cheers
Jon

p.s. the wmake log file is from 2 days ago, from my last git pull.

[wyldckat]

Greetings Jon,

Nice! I've always wondered if OpenFOAM runs on the latest generations of ARM processors.

If I understood you correctly, you're compiling OpenFOAM directly on that small desktop computer, correct? Because (theoretically) is should be possible to cross-compile on an i686/x86_64 processor and then pass the resulting binaries to the target machine, which is why I'm asking just to confirm this.

So, the first thing to check is: do the binaries see the library files? You can check this by running:

ldd $(which blockMesh)

The next thing is to check if the error code at the end is 0 or not. To do this, run:

blockMesh
echo $?

Then how about this command:

blockMesh -help

And when you run blockMesh in a tutorial, does it at least generate the mesh files or it doesn't even do that?

Best regards,
Bruno

[JonW]

Thanks for the quick reply Bruno

Yes I did compile OpenFOAM directly on that small desktop!
The arm is RISK, while the Intel x86 is CISC, so I dont think it will work to transfer the binaries directly.

Unfortunately "ldd $(which blockMesh)" gave nothing.

"blockMesh && echo $?" gave 1 (probably an error mark)

"blockMesh -help" gave nothing, unfortunately

Thus there is something fundamental wrong.

Thanks

[wyldckat]

Hi Jon,

Originally Posted by JonW

The arm is RISK, while the Intel x86 is CISC, so I dont think it will work to transfer the binaries directly.

If you use cross-compilation tools, you can compile binaries on x86 for ARM: http://en.wikipedia.org/wiki/Cross_compiler

Mmm... strange that ldd didn't give any feedback. OK, then let's go down to the basics:

1. Does this return the full path to the blockMesh binary?
   

   which blockMesh

2. If you run with the full path to it, does it give you the same return, i.e. no output?
3. Check the shell environment paths:
   

   echo $PATH
   echo $LD_LIBRARY_PATH

4. Use the application file which diagnosis what kind of file we're asking about:
   

   file $(which blockMesh)

Best regards,
Bruno

[JonW]

Hallo Bruno
First, thanks for the info about the cross-compilation tools. This could be a really good solution.

As you suggested I did the points you asked. Here are the results:

(1) which blockMesh, gives...
/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/bin/blockMesh

(2) run with the full path gave no output

(3a) echo $PATH, gives...
/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/gperftools-svn/bin:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/paraview-3.12.0/bin:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/openmpi-1.6.3/bin:/home/jonelvar/OpenFOAM/jonelvar-2.2.x/platforms/linuxARM7GccDPOpt/bin:/home/jonelvar/OpenFOAM/site/2.2.x/platforms/linuxARM7GccDPOpt/bin:/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/bin:/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/bin:/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/wmake:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/jonelvar/bin

(3b) echo $LD_LIBRARY_PATH, gives...
/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/gperftools-svn/lib:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/paraview-3.12.0/lib/paraview-3.12:/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/lib/openmpi-1.6.3:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7GccDPOpt/lib/openmpi-1.6.3:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/openmpi-1.6.3/lib:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7Gcc/openmpi-1.6.3/lib32:/home/jonelvar/OpenFOAM/jonelvar-2.2.x/platforms/linuxARM7GccDPOpt/lib:/home/jonelvar/OpenFOAM/site/2.2.x/platforms/linuxARM7GccDPOpt/lib:/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/lib:/home/jonelvar/OpenFOAM/ThirdParty-2.2.x/platforms/linuxARM7GccDPOpt/lib:/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/lib/dummy

(4) file $(which blockMesh), gives...
/home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/bin/blockMesh: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0x495a6955bdae3820686a0741dccfd0fed31a68fb, not stripped

Curiously, this line has "for GNU/Linux 2.6.31", while the linux version during compilation was 3.1.10.

B.t.w. I have been wondering if I should try to squeeze Fedora 19-ARM into the small pc, and try again. The fedora folks seem to be very committed to the arm architecture. But Im not sure, since I really like the Ubuntu-ARM (we will see what I will decide).

Cheers
Jon

[wyldckat]

Hi Jon,

The 2.6.31 reference might be the minimum compatible kernel version, or the minimum GLIBC version.

Well, there are a few more possibilities that come to mind:

1. Something that I've suspected before, but I was hoping it wouldn't be it. There might be a major problem with the interaction with the standard output, even though it built everything. I have no clue on how to solve this, if this is the case. But you might want to try redirecting the output to a file:
   

   blockMesh > log 2>&1

   Then check the contents of the file "log".
2. It's possible that there is a "ulimit" problem. Run this command to check any "ulimit" limitations:
   

   ulimit -a

3. It's possible that the problem is that Open-MPI is kicking and screaming all the way, without telling you a word about it. Try renaming the PStream folder for it... namely to rename this folder on the file system:
   

   /home/jonelvar/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxARM7GccDPOpt/lib/openmpi-1.6.3

   This will force the search for libraries to end up in the "lib/dummy", which has the basic serial running libraries.
4. Last but not least: have you tried compiling other software on that machine, besides OpenFOAM? Perhaps there is something else missing or broken.

Best regards,
Bruno

[JonW]

Hallo again Bruno and thanks for the replies so far.

Here are the results:
------------------------------------------------
1. "blockMesh > log 2>&1" gives nothing and the "log" file is empty.
------------------------------------------------
2. "ulimit -a" gives
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 4743
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4743
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
------------------------------------------------
3. "mv openmpi-1.6.3/ z1234", gives no change, tried both with blockMesh and icoFoam.
thus libPstream.so is not being called, regardless.
------------------------------------------------
4. Yes I have source in both C++ and Fortran and these compile and run just fine.
------------------------------------------------

I am starting to think this is a dead end.
This is not a critical thingi (is more a curiosity), since I will acces my main OpenFOAM computers through ssh on this small device.

Cheers
Jon

[wyldckat]

Hi Jon,

Well, unfortunately I'm all out of ideas. Well, at least ideas that don't require a lot of fiddling with OpenFOAM's source code.

I am curious to know how good/bad it would perform on ARM type processors, but I guess it will still take a while to get there .
Although that "armv71" entry in "etc/config/settings.sh" - https://github.com/OpenFOAM/OpenFOAM...ttings.sh#L117 - does give me hopes as well that said future is closer than we might imagine

Best regards,
Bruno

[JonW]

Great news Bruno
(at least I think this is it)

I was testing the opt parameters on some Fortran code I have. Without optimization, the Fortran code runs, and with the Openfoam optimization, the code don't run, don't do anything just as in the OpenFOAM case above.

By testing back and forth, then with "-mfloat-abi=hard" the Fortran code runs as normal, while with the standard OpenFOAM "-mfloat-abi=softfp" the code is silent and don't do anything. The softfp is supposed to be backward compatible to the soft-float OS (like Ubuntu 11.10 arm), as well to the new float architecture hard-float OS (like Ubuntu 12.04 arm and Fedora 18/19 arm). But apparently its not! In my case, I have to use "-mfloat-abi=hard" for the code to run.

I am going recompile OF with the new parameter and I will report back to you as soon as I'm finished.

Cheers
Jon

[JonW]

Great news Bruno!
OpenFOAM now compiles,
I have just tested interFoam and icoFoam, both runs without problems

thus, the approach is
1) cd OpenFOAM-2.2.x/wmake/rules/linuxARM7Gcc
2) nedit cOpt c++Opt &

In
c++Opt, then the following should be valid:
-------------------------
c++DBUG =
c++OPT = -O3 -floop-optimize -falign-loops -falign-labels -falign-functions -falign-jumps -fprefetch-loop-arrays -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=hard
#c++OPT = -O3 -floop-optimize -falign-loops -falign-labels -falign-functions -falign-jumps -fprefetch-loop-arrays -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp
-------------------------
The second lines was already present but commented (i.e. with #), thus the OpenFOAM developers already had the hard-float thingi in mind.

...same for the cOpt...
-------------------------
c++DBUG =
c++OPT = -O3 -floop-optimize -falign-loops -falign-labels -falign-functions -falign-jumps -fprefetch-loop-arrays -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=hard
#c++OPT = -O3 -floop-optimize -falign-loops -falign-labels -falign-functions -falign-jumps -fprefetch-loop-arrays -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp
-------------------------

... again the second line was already present. It is just about commenting and uncomennting the lines.

Now in my case I did...
3) export WM_NCOMPPROCS=2
4) foam
5) ./Allwmake

You have to repeat step 5 without step 3 above (of course with a new terminal).

P.s. paraview did not compile. This is OK, since I just use "foamToVTK" and thereafter "paraview &"

Now I have ultra small device that fits into my pocked that includes the newest version of OpenFOAM

Cheers
Jon

[wyldckat]

Hi Jon,

This is Awesome! Many thanks for sharing this information!

By the way, from your description, it seems that you are able to run ParaView on your small machine? Did you install ParaView by using Ubuntu's package manager?

Best regards,
Bruno

[JonW]

Hi again Bruno and sorry for the late reply. The answer to your last question is yes.
I.e. sudo apt-get install paraview (using /etc/apt/sources.list), with no problems

Cheers
Jon