[tgvosk]

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]

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
#or
make --version

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

Best regards,
Bruno

[tgvosk]

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
PARTICULAR PURPOSE.

This program built for x86_64-redhat-linux-gnu

[wyldckat]

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

[tgvosk]

Bruno,

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]

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]

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

"/home/servername/section/username"

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

[wyldckat]

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
wget ftp://ftp.gnu.org/gnu/make/make-3.82.tar.bz2
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]

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]

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: http://sourceforge.net/apps/mediawik...itle=Main_Page

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!
Bruno

[tgvosk]

Thanks for your help. CentFOAM installed without any errors!

[tgvosk]

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]

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]

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]

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]

Greetings to all!

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

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,
Bruno