CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Installation

OpenFOAM vs Ubuntu 10.10 64 bit

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   February 16, 2011, 13:20
Unhappy OpenFOAM vs Ubuntu 10.10 64 bit
  #1
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Hi all, I really don't know what the hell is going on with the installation of OpenFOAM on my new Ubuntu 10.10 64 bit based machine, so any help would be really appreciated...A brief summary of the story so far:

- I usually work on a Fedora based server and on my old notebook (Ubuntu 8.10). I've installed successfully on both of them OpenFOAM-1.6 (64 bit version on the server and 32 bit version on the notebook). After the installation I've also compiled my own modifications and add-ons to the source code and they work perfectly.

- Now I've changed my notebook and decided to install Ubuntu 10.10 64 bit and OpenFOAM 1.7.1 on it. Well, I've downloaded the source pack from the official OpenCFD site an built all (OpenFOAM and paraview) following the instructions: no errors, no strange messages, everything seemed ok, and in fact the tutorials worked perfectly.

- After that, I've implemented the same additional source code as before (basically a new turbulence model and a new wall function) and compiled it: after fixing some errors (probably due to slight differences between the 1.6 and 1.7.1 versions), the compiling procedure of the incompressible/RAS turbulence models source folder (./Allwmake) was succesfull, but the tutorials now have some strange issues with the wall functions (also with those I didn't touch at all) and during the first iteration a segmentation fault error causes the exit from the run.

- Well, maybe the problem was somewhere in the passage from 1.6 to 1.7.1, so ok, let's install the 1.6 64 bit version on the new machine! Again, downloading of the source pack and compiling, all seems good, the tutorials work. After that, compiling of the add-ons (this time with no errors at all) and....surprise! The same segmentation fault message! This is the error report form the airfoil2D tutorial (SpalartAllmaras model with nutSpalartAllmarasWallFunction at the wall, but the same is with other RAS models and wall functions):

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model SpalartAllmaras
SpalartAllmarasCoeffs
{
sigmaNut 0.66666;
kappa 0.41;
Cb1 0.1355;
Cb2 0.622;
Cw2 0.3;
Cw3 2;
Cv1 7.1;
Cv2 5;
}


Starting time loop

Time = 1

smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.00397212, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 0.00380162, No Iterations 2
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0818354, No Iterations 9
time step continuity errors : sum local = 0.000200831, global = 1.65043e-17, cumulative = 1.65043e-17
smoothSolver: Solving for nuTilda, Initial residual = 1, Final residual = 0.0191146, No Iterations 2
#0 Foam::error:rintStack(Foam::Ostream&) in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::incompressible::RASModels::nutSpalartAllmara sWallFunctionFvPatchScalarField::calcUTau(Foam::Fi eld<double> const&) const in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#4 Foam::incompressible::RASModels::nutSpalartAllmara sWallFunctionFvPatchScalarField::calcNut() const in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#5 Foam::incompressible::RASModels::nutWallFunctionFv PatchScalarField::updateCoeffs() in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6 Foam::fvPatchField<double>::evaluate(Foam::Pstream ::commsTypes) in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/simpleFoam"
#7 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/simpleFoam"
#8 Foam::incompressible::RASModels::SpalartAllmaras:: correct() in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#9
in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/simpleFoam"
#10 __libc_start_main in "/lib/libc.so.6"
#11
at /usr/src/packages/BUILD/glibc-2.9/csu/../sysdeps/x86_64/elf/start.S:116
Segmentation fault

Please, HELP!

V.

ps - I have gcc 4.4.5 on my system, don't know if it makes some difference...

Last edited by vkrastev; February 16, 2011 at 13:44.
vkrastev is offline   Reply With Quote

Old   February 17, 2011, 07:23
Default
  #2
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Well, I have rebuilt once again the 1.7.1 source packages, but this time changing the optimization level of the compiler from -O3 to -O1 (simply by editing the c++Opt and c++Prof files in the /wmake/rules/linux64Gcc/ folder). After that I have compiled also my own source code and now all seems to work perfectly...Does it mean that the 4.4.5 release of gcc has some optimization-level issues? I've read here OpenFOAM 1.6.x, 1.7.0 and 1.7.x are not fully prepared to work with gcc-4.5.x that in the recent past there were some troubles between gcc 4.5.x and OpenFOAM 1.7.0/1.7.1: could I have found some analogous problem with gcc 4.4.5 and OF 1.7.1 compiled on 64 bit machines? Or maybe the problem is somewhere else (processor architecture, or the specific combination of Ubuntu 10.10 and gcc 4.4.5)? I think these issues are quite interesting to start a debate, so any contribution would be really appreciated

Thank you in advance

V.
vkrastev is offline   Reply With Quote

Old   February 17, 2011, 07:53
Default
  #3
Senior Member
 
Laurence R. McGlashan
Join Date: Mar 2009
Posts: 370
Rep Power: 14
l_r_mcglashan will become famous soon enough
What happens if you compile OpenFOAM with -O3 and your own code with -O1 or -O2? Have a look at the difference between the options here: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
__________________
Laurence R. McGlashan :: Website
l_r_mcglashan is offline   Reply With Quote

Old   February 17, 2011, 09:06
Default
  #4
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by l_r_mcglashan View Post
What happens if you compile OpenFOAM with -O3 and your own code with -O1 or -O2? Have a look at the difference between the options here: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
If I build the whole code with -O3 and rebuild only the /incompressible/RAS folder with -O1 the result is the same as building all with -O3 (have in mind that my pieces of code are simply adapted version of pre-existing source files, so with the same type of basic structure and dependency lists), i. e. the same segmentation fault error appears. Actually I've made no extensive tests (e. g. switching from -O1 to -O2 or from -O2 to -O3 and deactivating the single additional flags) on what exactly should be the optimization flag (or flags) which causes such an error. In an older post I found that for gcc 4.5.0 there was a problem connected with the -fstrict-aliasing flag, and the problem disappeard when -fno-strict-aliasing was added along with -O3. However in my case this seems not sufficient (I've tried the compilation of the whole code with -O3 -fno-strict-aliasing and the same for the additional sources, but again the segmentation fault error appears). At the moment I'm quite busy with other issues, but I hope I could make some additional tests as soon as possible. Thanks for your reply (and for the useful link)

V.
vkrastev is offline   Reply With Quote

Old   February 19, 2011, 15:50
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,511
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings to both!

Vesselin, I've reported/accompanied the last two transitions in OpenFOAM 1.6.x to use gcc 4.4.x, as well as OpenFOAM 1.7.x to use gcc 4.5.x, as you have seen and can see here:
So, to the best of my knowledge, let me try to address one issue at a time:
  1. The original OpenFOAM 1.6 should not even build with gcc 4.4.5. You will need the fixes made by Mattijs in 1.6.x around November 17, 2009, in case you don't want to step up directly from 1.6 to 1.6.x.
  2. The changes you've added are they made directly to the core code of OpenFOAM or are they independent of the original code? Because if you added code directly to the original, then you'll need to analyse very closely the fixes made by Mattijs.
  3. On your changes, have you run this command:
    Code:
    wclean all
    This will clean up all of the objects used in the previous builds. Otherwise, you risk having old objects built with gcc 4.3.3 to contaminate the new builds with gcc 4.4.5! This has been know to complicate things.
  4. If you use different gcc versions to build OpenFOAM, you might end up with slightly different results in your cases. If you intend to reproduce the same results, using the same compiler version you used in your previous machine would be advisable!
  5. Although this is a long shot, have you tested the memory of your machine? It's unlikely, but my experiences in the last 12 months lead me to be more suspicious of machines with less than 12 months.
Either way, my biggest suspicion is that you didn't run "wclean all" on your code and that those libraries "contaminated the area". I suggest that:
  • If the changes are independent of the original code, then you should build one library at a time to try and isolate the issue.
  • If the changes are made directly to the original code, then the changes should be made gradually and not all at once.
Finally, when there are too many changes made to the code, it's better to play safe and run:
Code:
wclean all
wmake all
on the folder where you made the changes! This way you force a clean build.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   February 20, 2011, 11:06
Default
  #6
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
Greetings to both!

Vesselin, I've reported/accompanied the last two transitions in OpenFOAM 1.6.x to use gcc 4.4.x, as well as OpenFOAM 1.7.x to use gcc 4.5.x, as you have seen and can see here:
So, to the best of my knowledge, let me try to address one issue at a time:
  1. The original OpenFOAM 1.6 should not even build with gcc 4.4.5. You will need the fixes made by Mattijs in 1.6.x around November 17, 2009, in case you don't want to step up directly from 1.6 to 1.6.x.
  2. The changes you've added are they made directly to the core code of OpenFOAM or are they independent of the original code? Because if you added code directly to the original, then you'll need to analyse very closely the fixes made by Mattijs.
  3. On your changes, have you run this command:
    Code:
    wclean all
    This will clean up all of the objects used in the previous builds. Otherwise, you risk having old objects built with gcc 4.3.3 to contaminate the new builds with gcc 4.4.5! This has been know to complicate things.
  4. If you use different gcc versions to build OpenFOAM, you might end up with slightly different results in your cases. If you intend to reproduce the same results, using the same compiler version you used in your previous machine would be advisable!
  5. Although this is a long shot, have you tested the memory of your machine? It's unlikely, but my experiences in the last 12 months lead me to be more suspicious of machines with less than 12 months.
Either way, my biggest suspicion is that you didn't run "wclean all" on your code and that those libraries "contaminated the area". I suggest that:
  • If the changes are independent of the original code, then you should build one library at a time to try and isolate the issue.
  • If the changes are made directly to the original code, then the changes should be made gradually and not all at once.
Finally, when there are too many changes made to the code, it's better to play safe and run:
Code:
wclean all
wmake all
on the folder where you made the changes! This way you force a clean build.

Best regards,
Bruno
Hi Bruno, and many thanks for your detailed answer! Rereading your observations and suggestions, I think that:

1) When I built OF-1.6 after OF-1.7.1 this should have been done with gcc 4.3.3 instead of 4.4.5, as the 4.3.3 version is automatically provided with the 1.6 release and set as default once the environmental variables are pointed to the OF-1.6/etc/bashrc file. Thus, probably between the two consequent compilation there was this kind of "contamination" you are talking about (and this could be an explanation of the identical segmentation fault error displayed for both the OF versions).

2) The first time I compiled OF-1.7.1, the contamination could not have been possible...In addition, I'm sure I have done it all with gcc 4.4.5, and before building my modifications (which are not brand new libraries, but new source and header files based on the same dependency lists of the original ones) I've also cleaned the dependencies concerning the folder of interest (turbulence models/incompressible/RAS/). However, as the cleaning was done only with wclean (and not wclean all), could this have been (in your opinion) a source of troubles? In any case, I'll try to make some additional tests following your advices as soon as possible...

Thanks once again

V.
vkrastev is offline   Reply With Quote

Old   February 21, 2011, 06:07
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,511
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Vesselin,

Quote:
Originally Posted by vkrastev View Post
However, as the cleaning was done only with wclean (and not wclean all), could this have been (in your opinion) a source of troubles?
From my experience (and I could be wrong on some details), when we only run "wmake" on a library folder, it tries to build an executable, instead of a library; to build a library, we have to be explicit with "wmake libso", although I believe that "wmake all" will tell "wmake" to figure out what should be done, namely if to build an executable or a library.
So, since "wclean" is almost the opposite of "wmake", it should have similar functionality, namely the clean up process will depend on whether it's an executable or a library.

To make matters even more confusing, "wmake all" will call the local script "Allwmake" when it exists, since somethings are to be executed in different orders than usual. As for "wclean", it will call "Allclean". But usually only "Allwmake" exists in folders, while "Allclean" only exists sometimes.

As for contamination, there are at least two possibilities:
  • It usually occurs at an object level, namely ".C" files that have already been compiled with one compiler, thus creating the respective ".o" files, will then be used by another compiler. This sometimes works well, but when differences are too big between compilers, it won't work.
  • Another possibility that sometimes occurs, which usually happens when updating the git version of OpenFOAM, is that the building process doesn't detect new files that are needed for rebuilding the libraries and applications.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   February 21, 2011, 13:24
Thumbs up Problem solved
  #8
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10
vkrastev is on a distinguished road
Hi Bruno, I've just finishing rebuilding the code (1.7.1 release) and my modifications with the -O3 optimization level and now (finally) all works properly without strange error messages! I think that the issue was in the cleaning up of the dependency lists, because this time I've completed the cleaning/rebuilding procedure by using the combination wclean all/Allwmake. Thanks a lot for your comments and suggestions!

V.
vkrastev is offline   Reply With Quote

Old   February 23, 2011, 07:09
Default
  #9
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,511
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Vesselin,

I'm glad I was able to help and even happier that the issue you were having wasn't something related to a damaged CPU or RAM!

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   April 12, 2011, 12:10
Default My two cents
  #10
Senior Member
 
Adhiraj
Join Date: Sep 2010
Location: Pennsylvania, United States
Posts: 101
Rep Power: 6
adhiraj is on a distinguished road
Hi all,
I seem to have a similar problem, and it seems that the problem the OP had is related-- segfaulting in OpenFOAM. I can confirm this kind of behavior on both 64 bit and 32 bit Ubuntu 10.10. And if that is any help. the debug version runs perfectly fine.
adhiraj is offline   Reply With Quote

Old   April 13, 2011, 17:21
Default
  #11
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,511
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings Adhiraj,

Quote:
Originally Posted by adhiraj View Post
Hi all,
I seem to have a similar problem, and it seems that the problem the OP had is related-- segfaulting in OpenFOAM. I can confirm this kind of behavior on both 64 bit and 32 bit Ubuntu 10.10. And if that is any help. the debug version runs perfectly fine.
Soooo... have you followed the instructions on this thread to solve the problem?

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   April 22, 2011, 18:29
Default Solved that one
  #12
Senior Member
 
Adhiraj
Join Date: Sep 2010
Location: Pennsylvania, United States
Posts: 101
Rep Power: 6
adhiraj is on a distinguished road
Hi all,
sorry for the late reply; I've been simply swamped. I ran the wcleanall and recompiled everything, that seemed to help.
adhiraj is offline   Reply With Quote

Old   April 23, 2011, 10:14
Default
  #13
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,511
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Adhiraj,

OK, I'm glad it worked out well. I was worried that the instructions weren't clear enough, since I have a tendency to write too much

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
openfoam-1.6-ext on Ubuntu 10.10 Maverick rassilon OpenFOAM Installation 52 February 6, 2013 18:30
Error in apt-get update for installation of OpenFoam 1.7.1 on Ubuntu 10.10 StuntedChicken OpenFOAM Installation 1 January 9, 2011 11:43
OpenFOAM Installation Errors on Ubuntu 10.04 ozzythewise OpenFOAM Installation 1 June 19, 2010 05:59
How to Install OpenFOAM on 64 Ubuntu 9.04 hansel OpenFOAM Installation 62 March 19, 2010 15:43
OpenFoam 1.6 Permissions in Ubuntu 9.04 AlanR OpenFOAM Installation 14 December 28, 2009 20:45


All times are GMT -4. The time now is 18:15.