Error compiling OpenFOAM-1.6-ext
 

I understand the error for not being able to include "parmetis.h" . .but shouldn't the script download and install partmetis also ?? ..

I get:

Hello,

From your compilation message, we can see here :

-I/include/ParMETISLib -I/include

that some ThirdParty environment variables are not set.

As of now, I would recommend you compile OpenFOAM-1.6-ext in multiple phases in order to make sure all the ThirdParty environment variables are set up properly before compiling the bulk of OpenFOAM.

Something like that should work properly if you are using bash as your working shell:

#############################################

$WM_PROJECT_DIR/ThirdParty/AllMake.stage1 # Compile stage 1

. $WM_PROJECT_DIR/etc/bashrc # This will will initialize the CMAKE_DIR env. variable

$WM_PROJECT_DIR/ThirdParty/AllMake.stage2 # Compile stage 2

. $WM_PROJECT_DIR/etc/bashrc # This will will initialize the OPENMPI_DIR env. variable

$WM_PROJECT_DIR/ThirdParty/AllMake.stage3 # Compile stage 3

. $WM_PROJECT_DIR/etc/bashrc # This will will initialize many 3rdParty env. variable

$WM_PROJECT_DIR/ThirdParty/AllMake.stage4 # Compile stage 4

. $WM_PROJECT_DIR/etc/bashrc # This will will initialize the PARAVIEW_DIR env. variable

#############################################



Then compiling the rest of OpenFOAM-1.6-ext should run a bit smoother.

This is something that will be improved so that the global Allwmake will eventually take care of this for you. Thank you for your patience.

Martin

Hello,

I skipped Stage 2, because I already have openmpi. Stage 3 gives:

WM_MPLIB=SYSTEMOPENMPI, and sourcing etc/bashrc gives (verbose mode):

What does OPENMPI_DIR need to be set to, and do you know why it is not being set?

I tried this:
export OPENMPI_DIR=/usr/include/openmpi-x86_64

but then I get:

as the first error when building scotch.

This is on fedora 12:
Linux dali.como.group 2.6.31.12-174.2.3.fc12.x86_64 #1 SMP Mon Jan 18 19:52:07 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

re-source the bashrc should work.
source ~/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc

It seems that the environment is not updated after installing third party packages.

Junwei

I already tried that. locate mpi.h gives me:

/usr/include/openmpi-x86_64/mpi.h

but scotch doesn't find it?

Hello,

> I skipped Stage 2, because I already have openmpi. Stage 3 gives:

>What does OPENMPI_DIR need to be set to, and do you know why it is not being set?

The OPENMPI_DIR env. variable is not being set because you skipped stage 2.

Every ThirdParty package building stage will compile one or more ThirdParty packages, but will also generates a little .csh/.sh file that the file etc/settings.[csh/sh] will need to source. This is where the package specific environment variable is being set.

In order to better understand the new ThirdParty package structure, I would recommend you don't skip a stage for now in order to get a full running version of OpenFOAM-1.6-ext. It will only cost you some additional disk space and compilation time.

Then, once you've reached that goal of a working installation of OpenFOAM-1.6-ext, you can tweak the ThirdParty packages section of OpenFOAM-1.6-ext in order to use system-wide packages if you feel like it.

If you want to set the OPENMPI_DIR variable manually, the following paths need to be valid

$OPENMPI_DIR/include
$OPENMPI_DIR/bin
$OPENMPI_DIR/lib

This will be the same logic for all the ThirdParty package environment variables.

Another useful advice if I may: please activate the environment variable FOAM_VERBOSE before sourcing the etc/bashrc or etc/cshrc. You will see a bunch of useful messages related to the initialization of the Third Party packages

Martin

Ok, I'll install the lot for now. Something has gone wrong in stage 2:

and then:

Apologies, I've been rushing and will have to leave it there, as I'm going to watch Harry Potter! :D. I'll try to correct my haste/stupidity this afternoon sometime tomorrow.

Hello Laurence,

From what I can see, your system installation of openmpi is currently installed with the header files located under /usr/include/openmpi-x86_64.

So setting the OPENMPI_DIR variable to /usr won't be of much help if the file $OPENMPI_DIR/include/mpi.h can't be found anyways.

I will find a fix for this in order to facilitate the usage of system installed packages.

In order to help me help you, could you tell me how your system version of openmpi was installed on your Fedora 12 system?

In the meantime, you will need to be able to compile packages like openmpi on your machine.

The new ThirdParty package compilation process, including the successful compilation of openmpi 1.4.3, was tested on the following platforms:

Mac OS X 10.6 (Snow Leopard)
Ubuntu 10.04 32bit
Ubuntu 10.10 64bit
Centos 5.5 64bit
OpenSUSE 11.3 64bit
Fedora 14 32bit

It was not tested on Fedora 12 64bit.

Martin

What I'll do is try installing it on my Fedora 14 64 bit at home tomorrow. I should be able to do that as I know my own system inside out.

Then when I'm back at work on Monday I'll ask our system admin to have a look at our cluster installation and I'll let you know how it goes via this thread.

Thanks for the prompt help so far, it's very much appreciated.

Hello again Laurence,

I can replicate a similar configuration to yours when trying to use the sys-installed version of openmpi and openmpi-dev on my Fedora 14 system.

We are obviously aware of the advantage of using system installed versions of the ThirdParty packages. This was discussed before the release of OpenFOAM-1.6-ext, and we knew we would have to tackle that problem relatively quickly.

Let me use this use case in order to work on a more flexible solution for the ThirdParty package.

In the meantime, if you can find a way to compile openmpi on your Fedora 12 machine, you should be fine for all the libraries and packages that depends on it.

Thank you for your patience.

Martin

Hi Martin,

The new thirdparty structure is excellent, good job, Martin! and Thanks

Have you seen my bug report, on OpenSUSE 11.4 64/32 bits, concerning
some files missing

MsqIMesh.hpp
MsqIBase.hpp
MsqIGeom.hpp
MsqIRel.hpp
...

Errors look like these:
------------------------
+ wmake libso mesquiteMotionSolver
SOURCE=mesquiteMotionSolver.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -I/home/daniel/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/mesquite-2.1.2/platforms/linux64GccDPOpt/include -I/home/daniel/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/daniel/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicMesh/lnInclude -IlnInclude -I. -I/home/daniel/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/daniel/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/mesquiteMotionSolver.o
In file included from mesquiteMotionSolver.H:51:0,
from mesquiteMotionSolver.C:27:
/home/daniel/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/mesquite-2.1.2/platforms/linux64GccDPOpt/include/Mesquite_all_headers.hpp:33:23: fatal error: MsqIRel.hpp: No such file or directory
compilation terminated.
--------------------------------





Meanwhile, I found the most time consuming stage is paraview building process, and In my two laptops it keeps stuck at the stage 4, it seems the "%install" stage cannot be successful executed for rpmbuild, so no rpm generated. I think one of the most annoying things of rpm is that its compilation always needs to start over again, this is unaccepatable for package like paraview, since it takes around several hours to finish it. I changed rpmbuild -bb to -bi option to finish.
So is there any better idea to handle the paraview? I am afraid people will get crazy once stage 4 fails.


And also,
1. why not delete the obsolete buildinstructions.txt file?
2. why not add ThirdParty/packages to foamPackBin script? And publish the non-Debian binary files in sourceforge?

question about rpm
 

Hi

I have not tried this version, but just have a question from the information above.

It seems that the OF-extend 1.6 utilize rpm during the installing process. While installing rpm package requires root privilege, does this mean that we have to use root account during the installation process?

Thanks.

Answer: no, see the explanation in readme file in the thirdparty dir.

Hello Daniel,

@the Mesquite bug:
Yup, that one is fixed, thanks to Philippose Rajan.
I am currently testing the fix before pushing the correction on the git repo. Thanks for the report.

@the compilation of ParView:
Yup again, the compilation of QT and ParaView is a very lengthy and frustrating process because you often need to adjust your workstation for the missing bits and pieces necessary to compile those two monsters.

I have made a small modification to the RPM build process in order not to delete the package build directory at the end of the process. This way, the post-mortems will be easier to do, and it will be easier to fine-tune the compilation of a given package on your own machine until you get all the right dependencies installed on your compilation system. I am currently testing this as well. The changes will be pushed on the git repo shortly. Would that modification be useful to you?

@the file buildinstructions.txt:
Yup, we need to cleanup that file.

@adding ThirdParty/packages to foamPackBin script?
Simply put, I have never used foamPackBin, so it did not cross my mind to do this. That's easy to fix though.

@And publish the non-Debian binary files in sourceforge?
We have started talking about this.

Thanks for your great input!

Best,

Martin

That would be great, thank you! We'll see.

And you know, if paraview needs 2 hours to be built, the QT would need 6 hours. My point is this, QT is a much bigger monster than gcc, so let QT not be advised to build manually, ever. :) I have never heard a software being installed for more than half a day, lol

hello,
I have got the same issue of Daniel:
MsqIMesh.hpp
MsqIBase.hpp
MsqIGeom.hpp
MsqIRel.hpp
are missing.

Please let us know when you push the correction on the git repo or how to fix it.

Thanks a lot,
Matteo

Hi Matteo, I just copied these files from the source dir. :)

Hi Matteo, I just extracted Mesquite source, where there is a mesh/ dir. In mesh dir you will find these missing files, and then copy them to packages/mesquite../include

I see.. Thanks.
Generally I am bit worried about copying files around to fix issues.. but you are right, it is worth trying and if it fix the problem, that's it..

Thanks a lot,
ciao,
matteo

For different reasons I do not want to use the new procedure:

• I already have all the tools compiled
• I can not use wget behind my proxy

So I am looking for a way to simply modify the environment. However I can not see which .csh/sh-Files are used to modify the environment after each stage? I guess they are build after compiling each stage but it would be VERY helpful to have them available.

They (.csh/sh-Files) are quite simple, just look at the SPEC files, you'll see how they are generated.

I was able to pull the correction in commit 4fcfce1 (thanks Martin and Philippose), but a subsequent top-level Allwmake still leaves me with "no such file" errors on MsqIMesh.hpp, MsqIGeom.hpp, and MsqIRel.hpp. Is there something I need to do to "clean out" mesquite-2.1.2 in order for the correction to have an effect?

Ah - in retrospect, I see that the configure is run with --disable-imesh etc., whereas --enable-imesh would be needed for the .hpp file to be installed.

Hi,

I have the following errors in stage 4. How can I initialize QT-DIR? Will it fix the /bin/qmake issue too?

Thanks!

Pei-Ying
--------------------
========================================
Starting ThirdParty AllMake: Stage4
========================================

WARNING: Skipping the installation of ParaView-3.8.1.
WARNING: Please initialize the QT_DIR environment variable to your QT installation directory.
WARNING: The command /bin/qmake needs to be valid
WARNING:
========================================
Done ThirdParty AllMake: Stage4
========================================

I guess you could solve that by setting
export QT_DIR=/usr
before compile paraview.
But I am bot sure.

Hello Bastil,

I will contribute some modification for setting up the OF environment variables when you want to reuse your system-installed ThirdParty packages instead. You won't need any .csh/.sh files for this. Please note that this will need some additional testing before releasing, so thank you for your patience.

If you are in a hurry, then you can always download the various tarballs from another machine with a working wget command, and transfer the tarballs under the directory ThirdParty/rpmBuild/SOURCES. When the compilation scripts detect that the package tarball is already available, then wget is no longer invoke.

Martin

Probably right. The error message in AllMake.stage4 actually says
and $QT_DIR is expanding to an empty string in phsieh's case. I think single quotes instead of double or else a backslash in front of the $ would make the warning message more readable.

Hello David,

This is a nagging little problem. I though we nailed it down properly with the fix contributed by Philippose, but it looks like we need to revisit this one yet again.

Basically, all the configuration parameters for compiling Mesquite were recommended by Sandeep Menon, so I basically applied the same recipe.

I don't mind changing the configure parameters as long as the compiled mesquite library is still usable by OF-1.6-ext. I will contact Sandeep in order to get some advices over this one.

In the meantime, would you mind telling me on what platform/OS you are experiencing this problem? I am having a very hard time replicating this problem, and I am using 6 different Unix flavours for testing the new ThirdParty packages setup, to no avail...

Thank you for your input!

Martin

Yup, noted.

Thanks!

Martin

And, I mean no discouragement, I love the rpm idea too, it works very well in my laptop, and personal workstation, but since I met problems in installing the packages in our campus' high performance computer using rpm, which then makes me think, that whether rpm is a good idea for a "general" installation.

I advice that another way be simultaneously provided or kept, that is the way simply through something like Allwmake as in old Thirdparty dir. For not all the hardware setting is very suitable for rpm. We should give users more flexibility to install the packages more "manually". :D

And also I found the new scotch compilation is little tricky in some computer architecture, the Makefile.inc just doesn't work very well. :(

I'm using OpenSUSE 11.1, so I don't know if you want to bother replicating that one! Besides, looking into it, I see now why the fix contributed by Philippose should work. I just think that having already compiled mesquite, the damage was done and that I needed to wipe out mesquite and recompile it for the correction to take effect. Short of that, removing the pesky files from the Mesquite_all_headers.hpp is probably an easier patch than copying the files from the original src as suggested above.

And sure enough, Martin, of course you were right. With the latest commits, once I deleted mesquite from the packages and RPMs directories and re-ran the AllMake.stage3, all was well with the mesquite header files. Sorry for getting you off on a wild goose chase!

Good news! Looks like we can put that one to rest.

Martin

Compilation in SP
 

I ran into a problem with compiling 1.6-ext in SP. Where can I report a bug - it is not yet in the Bug-tracker?

Regards Bastian

compile ThirdParty packages
 

Hi,

I have a much simpler issue and will appreciate if someone here can help.

I have a computer that is not connected to the internet. When I issued the AllMake command in ThridParty, it looks like the script tried to download the source codes of the packages from the internet, and of course, failed. I can download all the packages manually from another computer which has access to internet, but, where do I put the source codes? Will the AllMake script knows where to find these packages without going to internet?

Pei

Look in ThirdParty/tools/makeThirdPartyFunctionsForRPM. On line 78, it checks first to see whether the "packageTarBall" is in the SOURCES directory (assuming it has not already found the rpm file).

Thanks a lot David and Daniel!

After seeting QT_DIR=/usr, paraview compiled, but, I got several link errors. Do I have to long in as root or use sudo?

Pei-Ying
---------------------
+ echo 'Generating OpenFOAM specific .csh and .sh files for the package ParaView-3.8.1'
Generating OpenFOAM specific .csh and .sh files for the package ParaView-3.8.1
+ echo ''

+ mkdir -p /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/BUILDROOT/ParaView-3.8.1-linux64GccDPOpt.x86_64//home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/etc
+ cat
+ cat
+ /usr/lib/rpm/brp-lib64-linux
sf@suse.de: if you find problems with this script, drop me a note
+ RPM_BUILD_ROOT=/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/BUILDROOT/ParaView-3.8.1-linux64GccDPOpt.x86_64
+ export RPM_BUILD_ROOT
+ test -x /usr/sbin/Check -a 1001 = 0 -o -x /usr/sbin/Check -a '!' -z /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/BUILDROOT/ParaView-3.8.1-linux64GccDPOpt.x86_64
+ echo 'I call /usr/sbin/Check...'
I call /usr/sbin/Check...
+ /usr/sbin/Check
Checking permissions and ownerships - using the permissions files
/tmp/Check.perms.j0x42f
setting /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/BUILDROOT/ParaView-3.8.1-linux64GccDPOpt.x86_64/ to root:root 0755. (wrong owner/group hsieh:users)
setting /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/BUILDROOT/ParaView-3.8.1-linux64GccDPOpt.x86_64/home/ to root:root 0755. (wrong owner/group hsieh:users)
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-symlink
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/qt4/lib -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/lib64
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/qt4/include -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/include
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/qt4/bin -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/bin
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/qt3 -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/lib/qt3
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/xulrunner-devel-1.9.1.13/include -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/include/xulrunner-1.9.1.13/unstable
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/xulrunner-devel-1.9.1.13/idl -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/include/xulrunner-1.9.1.13/unstable
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/xulrunner-devel-1.9.1.13/sdk/include -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/include/xulrunner-1.9.1.13/stable
Add the package providing the target to neededforbuild and Requires
ERROR: link target doesn't exist (neither in build root nor in installed system):
/home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/xulrunner-devel-1.9.1.13/sdk/idl -> /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/include/xulrunner-1.9.1.13/stable
Add the package providing the target to neededforbuild and Requires
INFO: relinking /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/packages/ParaView-3.8.1/platforms/linux64GccDPOpt/lib/paraview-3.8/ooo3/share/uno_packages/cache/uno_packages/oacnGn_/mysql-connector-ooo.oxt -> /usr/lib64/ooo3/share/extension/install/mysql-connector-ooo.oxt (was /usr/lib64/ooo3/share/extension/install/mysql-connector-ooo.oxt/)
error: Bad exit status from /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/tmp/rpm-tmp.v6e24b (%install)


RPM build errors:
Bad exit status from /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/tmp/rpm-tmp.v6e24b (%install)
Installing package: ParaView-3.8.1
Uninstalling ParaView-3.8.1 using RPM: ParaView-3.8.1-linux64GccDPOpt.x86_64
Installing ParaView-3.8.1 using RPM file: /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/RPMS/x86_64/ParaView-3.8.1-linux64GccDPOpt.x86_64.rpm
error: open of /home/hsieh/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/RPMS/x86_64/ParaView-3.8.1-linux64GccDPOpt.x86_64.rpm failed: No such file or directory
Done installing package ParaView-3.8.1

========================================
Done ThirdParty AllMake: Stage4
========================================

========================================
Done ThirdParty Allwmake
========================================

Hello,

Some important information is missing here:

What platform/OS are you using?
What is the version of QT installed on your machine?

Martin

Hi, Martin,

I am using OpenSUSE 11.3 64 bit OS. AMD Phenom II 955 CPU.
I believe that my QT version is 4.6.3-2.1.1

Thanks!

Pei-Ying

Hello,

I found the same behavior also on OpenSUSE 11.3 64 bit.
It seems that the rpm procedure copies a lot of files from the /usr/lib directory to the rpm installation directory. (I found there a copy of yast2!)

Norbert

I also got same error message on SUSE both for 11.2 and 11.3.
My Qt are respectively 4.5.3 and 4.6.3.