Greetings Venkatraman,
I know the feeling...

Disclaimer: I haven't tested this yet... But here are few guidelines:

1. Download the Third-party package from CentFOAM, chapter Manual install.
2. Unpack it in a temporary folder.
3. Read and implement point 3 from this page on your OpenFOAM installation: Automated scripts for building gcc 4.4.x and 4.5.x for using with OpenFOAM 1.7 series
4. When you've finished implementing point 3, start a new terminal and activate (i.e., source) OpenFOAM's environment. For example:
   Code:

   ---

   . $HOME/OpenFOAM/OpenFOAM-1.7.x/etc/bashrc

   ---

5. Now this command will tell you where, for example, gcc-4.4.4 should be installed:
   Code:

   ---

   echo $WM_THIRD_PARTY_DIR/platforms/$WM_ARCH$WM_COMPILER_ARCH/gcc-4.4.4

   ---

6. Go to the package you downloaded and extracted from CentFOAM, find that same folder and move its contents to the folder given in the previous command.
7. Now run:
   Code:

   ---

   which gcc
gcc -v

   ---

   It should show you where the visible gcc is placed and which version it is.

You could also try copying gcc 4.3.3 from the ThirdParty binary packages for OpenFOAM 1.6.

Now, this may or may not work, since there could be incompatibilities between the recent gcc builds and the old glibc version in RHEL 3/4.
And keep in mind that the gcc-4.4.4 version from CentFOAM is x86_64 only, so if your RHEL is x86, you will have to try gcc 4.3.3 from OpenFOAM 1.6. Run this if you don't know which one you have:Best regards,
Bruno

Thanks for your hints....I will try and let you know.

Hi Bruno, I'm back after my short holidays...I got my linux updated Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Client release 5.4 (Tikanga) and somehow managed:) to upgrade my compiler to gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/opt/gcc --program-suffix=444-real --with-ppl --with-cloog --with-mpfr=/opt/gcc --with-gmp --enable-languages=c,c++,fortran --enable-shared --enable-multiarch --enable-linker-build-id --enable-threads=posix --enable-checking --with-system-zlib --with-pkgversion=tygier Thread model: posix gcc version 4.4.4 (tygier) Now when I the ./Allwmake in the OpenFOAM-1.7.1 directory I'm getting a lot of messages like(just one of them pasted below) SOURCE=topoChangerFvMesh/topoChangerFvMesh.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/dynamicFvMesh/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/dynamicMesh/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/meshTools/lnInclude -IlnInclude -I. -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/topoChangerFvMesh.o /bin/sh: g++: command not found and eventually terminates with errors... I guess this means that it cannot find the g++ compiler... When I pick one of the above messages and replace g++ with g++444 which is my new compiler it runs.... Do you have any idea where can I alternate something so that this g++ is replaced by g++444....I hope to get it solved by that.... Looking forward to your reply. Thanks

Hi Bruno, I'm back after my short holidays...I got my linux updated Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Client release 5.4 (Tikanga) and somehow managed to upgrade my compiler to gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/opt/gcc --program-suffix=444-real --with-ppl --with-cloog --with-mpfr=/opt/gcc --with-gmp --enable-languages=c,c++,fortran --enable-shared --enable-multiarch --enable-linker-build-id --enable-threads=posix --enable-checking --with-system-zlib --with-pkgversion=tygier Thread model: posix gcc version 4.4.4 (tygier) Now when I do ./Allwmake in the OpenFOAM-1.7.1 directory I'm getting a lot of messages like(just one of them pasted below) SOURCE=topoChangerFvMesh/topoChangerFvMesh.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/dynamicFvMesh/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/dynamicMesh/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/meshTools/lnInclude -IlnInclude -I. -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/joseph/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/topoChangerFvMesh.o /bin/sh: g++: command not found and eventually terminates with errors... I guess this means that it cannot find the g++ compiler... When I pick one of the above messages and replace g++ with g++444 which is my new compiler it runs.... Do you have any idea where can I alternate something so that this g++ is replaced by g++444....I hope to get it solved by that.... Looking forward to your reply. Thanks

Hi Jonhy,

Wow, your posts got somehow super condensed :confused: Suggestion: use Advanced mode for editing your posts!

And that update to gcc 4.4.4, you should share how you got it done ;)
As for your problem with g++444, see this explanation: OpenFOAM install on RHEL 5.5 post #2

Best regards,
Bruno

Just noticed that the command "which gcc" gives /usr/bin/gcc (where gcc lies) against /opt/gcc/bin/ where g++444 lies......

OpenFOAM1.7.x installation on RHEL 4.0 cluster
 

Hello Bruno,
I followed your guidelines as u mentioned in last reply. I will explain you in detail so that if I miss anything you may able to guide me better.

1. I downloaded the OpenFoam1.7.x and extracted and renamed in home/OpenFoam/OpenFOAM-1.7.x

2. Then the Thirdparty1.7.0 was also downloaded and renamed as Thirdparty-1.7.x

3. As you said , the compiler of the system was changed in to OPENFOAM in the sttings.csh and the versions are changed into 4.4.4 for gcc.

4. Since i use X86_64 arcitecture in the OpenFoam cshrc file I changed the commands in gcc and g++ to gcc44 and g++44

5. I sourced the openFoam cshrc file

6. In the downloaded CENTFOAM third party i found a directory platforms/linux64/gcc4.4.4 . But this platforms directory was not there in the Thirdparty1.7.x stuff that i downloaded from the git repository. So i copied the directory 'platforms' completely and pasted it in the ThirdParty 1.7.x.

7. gcc -version gives GCC-4.4.4 and it is pointing the right location.

8. Then I executed ./Allwmake > log.allwmake


But there are many errors displayed in the terminal window. However they are not shown in log files. I hereby attach the log output file for your reference. If you can have a look at it it will be useful to me.

Thanks and Regards

Greetings Venkatraman,

Please run again but like this:
This way the errors will also be outputed into the log file.

All I can figure out is that something very weird is happening, due to binaries being built as "OpenFOAM.out" :confused:

So, my guess is that it's either flex or binutils that is missing...

Best regards,
Bruno

Dear Bruno,
I hereby attached the Log files with error messages. I checked Flex version it says flex 2.5.4 and Bison 1.875c .

If you can tell me what are the packages that are missing for RHEL 4.0 X86_64 , to install OF 1.7.x then it will be useful. I had an Appt with LINUX admin tomorrow, If you cna tell me either by today or tomorrow it wil be useful.

Thanks and Regards

Hi Venkatraman,

Bad news, the gcc version you've got doesn't work :(

Try following this tutorial and you will see what I mean: Compiling a simple C++ program

You better ask your system's administrator to build you an updated gcc, either 4.4.4/4.4.5 or 4.5.1, including the latest binutils. Apparently the version built the CentOS 5.x is too much in the future for possible compatibility with RHEL/CentOS 4.x.

If your system's administrator can't build an up-to-date gcc+binutils, try installing CentOS 4.x in a virtual machine, build gcc+binutils (and maybe OpenFOAM as well) and then copy the resulting build to your RHEL 4 machine.

Another way to check if gcc is working is to run this:
This should build wmake's assistant tools: wmkdep and dirToString. Without these, you won't be able to build OpenFOAM.

Best regards and good luck!
Bruno

Dear Bruno,
You are right ! The gcc4.4.4 provided by CentFOAM is not compatible to build OpenFOAM1.7.x on RHEL 4.0 . This was not possible with my experience.

Now Iam building OpenFOAM on CENTOS-5.5 on a seperate workstation. I followed the steps for manual installation provided in CentFOAM website. OF1.7.0 was installed without any flaws.

Then I downloaded OF1.7.x and changed the settings for gcc compiler from system to OpenFoam and version 4.4.4 in settings.sh. Path is also set using alias command for .bashrc file .

For the thirdparty directory , i copied the existing Thirdparty-1.7.0 (from centFOAM)and just renamed the director y as ThirdParty- 1.7.x. I got only one error as of now. Could you tell me what is the problem.

make:*** [/opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libscotchDecomp.so] Error 1


Thanks

Hi Muthu,

:eek: I'm gonna need to know more than that ;)

Run Allwmake like this:
Then please post the compressed log file; otherwise I can only make wild guesses, such as:

• libscotch didn't build properly...
• OpenMPI wasn't properly built or something...

Best regards,
Bruno

Hi Bruno,
Sorry that I couldn't share my experience. I was just away for a week on official reasons. Anyway it seems that my installation really didn't work well(even after trying to get the compiler linking issue in order) and there were a lot of compiler incompatibilites and dependencies error that my colleague decided to get a fresh installation.

Could you please shed some light in the following 2 issues regarding bc's

1)How can I mention the inlet velocity in OpenFOAM when the boundary under consideration is a curved surface of a cylinder and flow(inlet velocity) should be tangential(or lets at an angle to the normal) to this surface and away from the axis of this cylindrical surface. Basically this cylindrical surface is an inlet to a cabin and air is drove into the cabin with a fan alligned to the axis of the surface(cylindrical)

2)Here again is about the inlet velocity bc. In the wind tunnel simulation flow enters the tunnel through the inlet normal to the inlet surface. But if I want to mention the velocity at an angle to the to inlet surface, how can I do it.

I would greatly appreciate a reply and looking forward to it...

Cheers !!!

Hi Johny,
A very wise decision :)

:( I'm so sorry, but on those types of questions, I don't know much (--> here <-- is more about what I do and don't know ;)). And I believe it's best that you ask those questions on the dedicated section of this forum: OpenFOAM Running / Solving / CFD
Or like many people do, ask on the main OpenFOAM forum.

---------------------

OK, the rest of this post I will use for my report on my experiences this weekend with CentOS:

• I've installed in 4 virtual machines the CentOS i386 versions 3.3, 3.9, 4.0 and 4.8. The first 3 were downloaded from CentOS's vault.
• In all of them I was successful in building OpenFOAM 1.7.1, without much effort.
• Each machine was configured with 20GB of disk, 1.6GB of RAM, 4 cores and always installed CentOS in Workstation mode, since it already comes with development tools pre-installed, so I didn't need to mess around with the package manager nor yum :)
• All of these CentOSes come with flex 2.5.4, which was more than enough for building OpenFOAM 1.7.1.
• All of them come with gcc series 3.x.x, which was more than enough for building make, binutils and gcc 4.4.4. I haven't tried gcc 4.5.1, but it should well enough as well :)
• In CentOS 3.x versions, I had to build a more recent GNU make, but I've just included it in my build-gcc scripts (see here).
• Other than this, I didn't need to build a new flex, nor need to build any other more recent tools!

So, it's pretty simple:

1. follow the instructions in www.openfoam.com for building either OpenFOAM 1.7.1 or 1.7.x (although I haven't tried the git versions that come with these CentOSes)...
2. BUT just before you run Allwmake, follow the instructions on this blog post: Automated scripts for building gcc 4.4.x and 4.5.x for using with OpenFOAM 1.7 series
3. After this, keep following the original instructions for building OpenFOAM and you should have it all working after a few hours.

I didn't try to build ParaView in these CentOSes, since that's a whole other ball game ;)

As for that previous issue reported on this thread, namely post #19, it probably happened solely because there was a folder path in the environment variable LD_LIBRARY_PATH that carried a "rogue" library... which could be the pre-built ParaView 3.8.0 available only. In such a scenario, it's necessary to neutralize that path... and such explanation will have to wait for another time, because I don't want to over-post ;)

So, to conclude:

• If you do have an RHEL 5.x, try CentFOAM first.
• For those people who need to build OpenFOAM in an old RHEL (version < 5.0), have no root access to that machine, you can try at first following these instructions above. If they don't work, install CentOS of the same version as your RHEL, in a Virtual Machine or on a real machine, and be sure to install the Workstation version (question appears during installation). Then follow these instructions again. When done, pack the whole OpenFOAM folder and take it to your RHEL machine and modify OpenFOAM-1.7.1/etc/bashrc if necessary, to adapt the folder paths.

Good luck! Best regards,
Bruno

Dear Bruno,
I hereby attach the compressed log file to see the details of comiplation. Actually I can able to run foamInstallationTest and it says all crictical systema and basic configurations are Ok. I also ran some testcases and the results are okey.

But still I want to make it sure that this Error comes from where ? Does it has any influence later ?

Thanks

Dear Muthu,

The only error there is in the log file is for libscotchDecomp, just as you previously posted about. Sorry about that, I didn't understand before that this was the only error. The solution is quite simple: run Allwmake again and the error will be solved :)

The error is one of the issues I've recently reported to OpenCFD's bug tracking system: Best regards,
Bruno

Thanks a lot Bruno! I will do it as you said. This clears my mind :-) .

Hello,

I installed 1.7.x on a computer cluster and I am trying to do some parallel runs with the cavity case. All goes well, when I type my commands manually:
If I want to user different nodes, I qsub a file named run.sge which contains this:
I have a similar error message to msuho in #19 in my log file (see log.txt)

Can anybody tell me what the problem is?

Problem ist that the libstdc++ that it finds on the cluster is WAY too old. Let the script output

echo $LD_LIBRARY_PATH

and

ldd interFoam

(or whatever your solver is). Compare the outputs. See what is there. Is your cluster and your workstation the same RedHat-release? Which gcc did you use for compilation (maybe you'll have to install the compiler - or only the standard libraries that come with it - on the cluster too)

Bernhard

Thank you.

I am not sure my libstdc++ is too old, since I used gcc-4.5.1.

What I do not understand is the following : Both simulations I describe above were tried on the same cluster, with CentOS release 5.4 (Final). When I type the commands one by one, it works, but when I use the run.sge, the troubles come.

I added the lines to run.sge. echo $LD_LIBRARY_PATH gives
ldd icoFoam gives an empty output, or when I type it directly in the terminal it gives
ldd: ./icoFoam: No such file or directory

So I went into OpenFOAM/OpenFOAM-1.7.x/applications/bin/linux64GccDPOpt and then typed ldd icoFoam, which gave

I am not sure about what this means, but I think the problem is not in libstdc++, since for both the library is in /share/apps/gcc-4.5.1/lib64/libstdc++.so.6.

Don't you think the problem is somewhere in the run.sge file?