|June 23, 2014, 06:04||
foam-extend-3.1 on CentOS 6.5
Join Date: Mar 2009
Posts: 537Rep Power: 17
A Very Good Morning to everyone :-)
I assume you are all busy with the 9th OpenFOAM Workshop in Zagreb.... Unfortunately, I havent yet got the opportunity to make it to one yet...
I just finished compiling foam-extend-3.1 on a 64-bit standard CentOS 6.5 installation, and have a couple of points to mention....:
1. The compile / install workflow was the smoothest so far :-) So great work everyone :-) Sorry for not being more involved during the test / release phase this time
2. I commented out the compile and install of "bison" in the Thirdparty set because there was already a version of bison installed on CentOS.
3. There is a problem with Qt.... The standard version of Qt on CentOS 6.5 is 4.6.2 which is too old for Paraview 4.x.x. Which implies, that using the Thirdparty installation of Qt might be better.
However, the Thirdparty system tries to download and compile "Qt 4.8.5". The problem is.... Qt 4.8.5 is not available on the Qt-servers anymore. The only version of the Qt 4.x.x series which can be downloaded from the servers is now "Qt 4.8.6".
I created a new RPM spec file which is essentially a copy of the spec file for 4.8.5 and replaced 4.8.5 with 4.8.6. This successfully downloaded and compiled Qt-4.8.6
Once that was done, I could compile Paraview-4.0.1 without any further incident, and the Paraview plugin for OpenFOAM compiled fine too.
4. There is a problem with PyFoam..... The active version (one not commented out in the git master branch) used within the Thirdparty AllMake.stage3 points to PyFoam-0.6.3, whereas the download link for this version points to PyFoam-0.6.1. This causes a conflict in the installation not just because of version number but also something to do with "noarch" and "x86_64" RPM files.
I ended up using PyFoam-0.6.2 by uncommenting the right line in AllMake.stage3
In order for these version changes (Qt, PyFoam, etc...) to work successfully, one also needs to change the hardcoded version numbers in the "etc/settings.sh" file, so that the right startup scripts are called.
I guess one possible need for change in a future version would be to somehow avoid hard-coding the version numbers for the various Thirdparty libraries in the "etc/settings.sh" file.... How exactly this can be done in a flexible manner is something I need to put some thought into.
Hope this helps. I was not sure whether all this belongs to the OpenFOAMWiki website or not.... and whether the issues need to be reported as bugs or not....
Have a wonderful time at Zagreb :-)
|Thread||Thread Starter||Forum||Replies||Last Post|
|error message with modeling a cube with a hold at the center||hsingtzu||OpenFOAM Native Meshers: blockMesh||2||March 14, 2012 10:56|
|mesh airfoil NACA0012||anand_30||OpenFOAM Meshing & Mesh Conversion||12||December 12, 2011 05:16|
|BlockMesh FOAM warning||gaottino||OpenFOAM Native Meshers: blockMesh||7||July 19, 2010 14:11|
|Axisymmetrical mesh||Rasmus Gjesing (Gjesing)||OpenFOAM Native Meshers: blockMesh||10||April 2, 2007 14:00|
|Import gmsh msh to Foam||adorean||Open Source Meshers: Gmsh, Netgen, CGNS, ...||24||April 27, 2005 08:19|