CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Installation (
-   -   OpenFOAM 2.1.1 Installation Errors on RHEL 6.3 (

tgvosk July 3, 2012 10:37

OpenFOAM 2.1.1 Installation Errors on RHEL 6.3
I am trying to install OpenFOAM 2.1.1 on RHEL 6.3 (using gcc 4.4.6) in my $HOME/OpenFOAM directory per the source pack instructions. After setting the environment variables, foamSystemCheck gives a "PASS".

Then, running Allwmake starts giving numerous "*** target pattern contains no `%'. Stop." messages, then begins throwing actual errors when it gets to autoRefineMesh (output below). Any help would be greatly appreciated!

[excerpt from Allwmake output]

+ make prefix=$HOME/OpenFOAM/ThirdParty-2.1.1/platforms/linux64Gcc/scotch_5.1.11 libdir=$HOME/OpenFOAM/ThirdParty-2.1.1/platforms/linux64GccDPOpt/lib/openmpi-1.5.3 includedir=$HOME/OpenFOAM/ThirdParty-2.1.1/platforms/linux64Gcc/scotch_5.1.11/include/openmpi-1.5.3 install
cp: cannot stat `../bin/[agm]*': No such file or directory
make: [install] Error 1 (ignored)
+ make realclean
+ wmakePrintBuild -check
no git description found
+ /bin/rm -f 'OpenFOAM/Make/*/global.?'
+ wmakeLnInclude OpenFOAM
+ wmakeLnInclude OSspecific/POSIX
+ Pstream/Allwmake
+ wmake libso dummy
$HOME/OpenFOAM/OpenFOAM-2.1.1/wmake/Makefile:148: *** target pattern contains no `%'. Stop.
$HOME/OpenFOAM/OpenFOAM-2.1.1/wmake/Makefile:148: *** target pattern contains no `%'. Stop.
+ case "$WM_MPLIB" in

[ these warnings continue for awhile, then it encounters an error at autoRefineMesh ]

+ wmake all utilities
$HOME/OpenFOAM/OpenFOAM-2.1.1/wmake/Makefile:148: *** target pattern contains no `%'. Stop.
make[2]: *** [autoRefineMesh] Error 2

[ and the errors propogate until compilation stops ]

wyldckat July 3, 2012 16:42

Greetings Tyler and welcome to the forum!

According to what I searched based on that error message:

target pattern contains no `%'.
all points to one thing: incompatible make application/version.

What specific version of make are you using?

make -v
make --version

And is it "GNU Make" or some other make?

Best regards,

tgvosk July 3, 2012 16:46

Make version
I am using GNU make version 3.81.

GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

This program built for x86_64-redhat-linux-gnu

wyldckat July 3, 2012 16:49

Hold on... is "$HOME" copy-paste-replace by you or does it really exist as a folder named "$HOME"!?!?

tgvosk July 3, 2012 16:50


I copy-pased $HOME in to make the message more brief and protect my username. The actual message shows my full home path where I have inserted $HOME.

wyldckat July 3, 2012 17:02

OK, then to protect your information, a couple of details would be welcome:
  1. Any spaces in those omitted folder names?
  2. Any special characters? Such as:
  3. Any special mount address? Something like ":/smbmount/username"
  4. Is the username one of those crazy long CLSID names, like: 24123-EAB3124-1523413

tgvosk July 3, 2012 17:05

No to all four questions. The home directory is of the format


All names are short, and contain nothing but lower case letters.

wyldckat July 3, 2012 17:28

OK, took me a bit longer because I was doing some other stuff and testing this as well - these commands will build you another GNU Make, version 3.82, which hopefully will fix the problem:

mkdir sandbox
cd sandbox
tar -xf make-3.82.tar.bz2
mkdir makebuild
cd makebuild
../make-3.82/configure --prefix=$HOME/make
make -j 4
make install
export PATH=$HOME/make/bin:$PATH
make -v

If the 3.82 shows up, try running Allwmake once again!

tgvosk July 3, 2012 17:45

Thanks for the quick replies. I got the GNU make 3.82 installed and set up (make -v returned 3.82) but when I ran Allwmake I got the same errors as before.

I have been looking through the makefiles trying to find where the errors are coming from, and the errors start when "wmake libso dummy" is called in src/Pstream.


$ cd src/Pstream; wmake libso dummy
/home/server/section/username/OpenFOAM/OpenFOAM-2.1.x/wmake/Makefile:148: *** target pattern contains no `%'.  Stop.
/home/server/section/username/OpenFOAM/OpenFOAM-2.1.x/wmake/Makefile:148: *** target pattern contains no `%'.  Stop.

The "files" file in "dummy" is using $FOAM_LIBBIN, which is currently set on my system as $HOME/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOps/lib", however the "platforms" folder does not yet exist at the point when this is called.

I do not know when the platforms folder ought to be created a the normal installation.

wyldckat July 3, 2012 17:55

Arg... I can't figure out why it's giving that error... maybe I'm just too tired to imagine the reason :(

OK, I didn't mention this before because I wasn't sure if it was updated, and my guess was that RHEL 6.3 would be up to code on this, but apparently it isn't all that simple :(
Anyway, the thing I didn't mention before is this - CentFOAM:

CentFOAM - OpenFOAM for RHEL x86_64 based systems
It's now updated to 2.1.1, so hopefully things will work as intended...
Although I think it still assumes that you install ParaView manually...

If you search the OpenFOAM forum for "CentFOAM", you should pick up on some more hints ;)

Best regards and good luck!

tgvosk July 3, 2012 18:40

Thanks for your help. CentFOAM installed without any errors!

tgvosk July 5, 2012 15:44

As an update:

Although CentFOAM installed easily, I still could not compile my own solvers because of the same error.

However, I was finally able to figure out what was causing this error. On my system, the default value for the environment variable $GREP_OPTIONS includes a "-n" option to print a line number in the output of grep. Since the wmake script "makeDerivedFiles" uses "grep" to build the intermediate files (located in Make/linux64GccDPOpt), they were all ending up with a line number when they shouldn't have.

Changing $GREP_OPTIONS from "--color=auto -n" to "--color=auto" before running fixed the problem.

I would suggest that the "makeDerivedFiles" script be modified to guard against this. I did this by adding

export GREP_OPTIONS=""
immediately before the first "grep" in the makeDerivedFiles script.

l_r_mcglashan July 5, 2012 16:11

It would be much safer to use an alias for grep rather than set grep_options. It's not just OpenFOAM that could be affected by having grep_options set!

tgvosk July 5, 2012 16:39

I am not suggesting that the script set GREP_OPTIONS globally. I am suggesting that the script unset GREP_OPTIONS locally while running, in case the user has GREP_OPTIONS set. Running "export" in the shell script will not affect the value of GREP_OPTIONS outside the script and its children so it won't affect anything except the script in question.

l_r_mcglashan July 5, 2012 16:53

I know that. I just suggested that using aliases would be safer for you than setting grep_options. What will you do when you use another script or program that uses grep and your grep_options choices break it?

wyldckat July 5, 2012 18:43

Greetings to all!

(Warning: I'm going to almost rant a bit more on this subject...)

:eek: Simply googling for "GREP_OPTIONS", returns two top hits indicating:
  1. GREP_OPTIONS considered harmful
  2. GREP_OPTIONS is evil
Going on checking other links shows that there way too many scripts and applications out there that are as susceptible to this issue.

Running "unset GREP_OPTIONS" inside the scripts might be a good idea, since this would bullet proof the scripts a little bit. The downside is that this probably would mean that additional bullet proofing might be necessary for sed, awk, and any other GNU tool that OpenFOAM uses.

On the other hand, the great thing about aliases is that they die out as soon as another script is launched. It's also annoying, because sometimes said aliases do come in handy in scripts as well... but alas they don't work.

My guess is that a half-way fix would be more helpful: adding the detection and giving a warning of potentially harmful environment variables to OpenFOAM's "settings.*" files could be a win-win solution!

Uhm... a bit of searching in man for sed, awk and wget didn't give me any other environment variables that could be harmful...

Best regards,

All times are GMT -4. The time now is 22:07.