OpenFoam 1.6-ext - RPM build errors
 

Hallo everybody

I want to install OpenFOAM 1.6-ext. First I tried to make the Thirdparty software: ./AllMake.stage0 ... 2 all is fine! But in stage 3 are some errors :confused::
Can somebody help me?!

Preibie

AllMake ThirdParty OpenFOAM1.6-ext
 

Your system seems to be missing 'patch' - try this:

On debian or U|K|X ubuntu:
# apt-get install patch

On (open)SUSE:
# zypper install patch

On RHEL / CentOS:
# yum install patch


... and rerun AllMake

While we are on the topic... isn't the whole third party RPM mess that the Extend project uses completely ridiculous? It buys the user nothing, and it looks like more work went into it than if they were to just do make scripts that did "configure/make/make install". My cluster, as I would assume is the case for many other people, does not have internet access, so I have to download all of the libraries individually on another machine and transfer them over. Would it not be more strait forward to just provide a third party sources tarball? And why the hell would I need a different path and library path for each third party tool? If you are not going to install them to the system paths, at least use one common location for all of them!

I really wish the Freefoam project took hold.

Thanks andras,

you are right :) on my system patch was missing! Now the thirdparty software is installed.

Preibie

After installing all the rest of OpenFOAM 1.6-ext and running foamInstallTest the following message was shown:
Something is curious, I tried blockMesh and icoFoam all is fine!:confused: What is the critical error?

Preibie

OF Installation
 

@ kyle:
I can not agree more. The OpenFOAM(-ext) compilation process is a complete and utter mess - unless you use the exact compiler and library versions of the system it was developed on. This information however is willingly undocumented (among many other things) by the project team. My experience is that the compilation of the main OpenFOAM release (1.7.1) is much easier in this respect.

IMHO not much time is spent by the developers to make it install in a clean and predictable way on linux - I'm not even talking about other UNIX like OSs. wmake for example does not check the dependencies (compiler, linker, libraries, etc.) of the build process and blindly runs into avoidable errors during the long build. Certainly there is a lot to improve. The project's emphasis is clearly not portability or case compatibility between different releases...



@ preibie:
I think everything is all right if you can run the tutorials.



Cheers,
Andras

@kyle and andras

I work at a software company so I know how much time and effort it requires (hint: its non-negligible) to get software to compile and install uniformly on different Linux flavors.

Furthermore, I would imagine the main devs would welcome you volunteering time to test the build and installations on other distributions. Remember, it's an open community - if you don't like something fix it or ask how you can help make it better.

@cnsidero

I am not knocking the effort they have put into the project, only the design of the third party tools install scripts. It appears that significant work was done in this area when just keeping OpenCFD's solution would have been preferable. I am actually suggesting that the Extend developers should have expended LESS time and effort.

I am well aware how difficult it would be to create a rubust build system that worked on every architecture and OS that OpenFOAM supports.

I would tend to disagree with this. If you take a quick survey of the forums on how many threads discuss difficulties building and installing ThirdParty packages (dependencies on specific gcc and Qt versions were probably the most), I don't think OpenCFD's version is any better (e.g. paraFoam). FWIW, this is a just a observation - I don't have numbers so I could be wrong.

I believe the intent of moving to a different build structure for the extend version was to have it automatically resolve the dependencies of the ThirdPary packages (i.e. if it's not installed, download the source, build and install it). Of course a new build system introduces new tools which adds different dependencies and other possible issues. The extend devs could probably provide a more appropriate response.

Plus, realize it is new and hasn't been abused by the user community much. Once it has been exposed more, bugs and other problems will get sorted out. Hence, my suggestion to contribute.

Hello

@ kyle
I somewhat agree, but I would believe there is some "behind the scene" reason why they opted to switch to this approach.


@ Everybody
1.6-ext build process is better in some aspects, for example having ThirdParty in the same folder as OF makes a whole lota sense for me.

in general if you do not want to build OF all the time I suggest you pick a linux distro and stick with it. Then put your compiled OF into a tar.gz file and store it a safe place. Preferably you choose a LTS (long term support) like ubuntu lts or RHEL/CentOS/SL or SLES to avoid EOL (end of life) in only 6months. There are a lot of people hosting different pre-built packages for the most popular distros. Myself I host a build of OF 1.7 and 1.6-ext for RHEL/CentOS/SL 5.x-x86_64.

The clusters I maintain and workstations I use are all installed with CentOS and installing OF/netgen/paraview/gmsh/engrid is as simple as downloading my install script and running it.

The pain of getting used to a new linux OS, even though their appear to be similar, can be long and troublesome because the differences lie in the details. Like where is the library files located. Can be /usr/lib or /usr/lib64 or usr/local/lib, etc. depending on the os.

I've tried maybe 15 different linux OS's, but nowadays I just use CentOS. You don't get the fancy new desktop effects out of the box, but it just works and its stable and it is supported well into the future.

So to sum up if you do not want do deal with the hassle of compiling OF and just want to do CFD, skip the steep learning curve and install a pre-built version and go directly to the even steeper learning curve of doing proper CFD with OF.:)

@ linnemann

Hear, hear!

Hi everybody,

i just got a new OS running openSUSE 11.4. I tried to compile of 1.6-ext and got an error at stage 3 compiling mesquit. It says

What I found out, that it is maybe because of a (missing) 32bit fortran compiler but I never found any similar problems. Any ideas or suggestions?

Greetings

[edit]gcc-fortran solved the problem..[/edit]

Parmetis is the only package that doesn't installed could someone tell me what the problems is
** I installed 32-bit version, thats how I solve this problem **