Thanks Manuel and Tek Seang,

I still cannot compile gcc 3.4.3 on my sgi machine. I get the same error I reported some threads earlier (problems with 'config.h') and I can't build gcc 3.4.3.

Manuel:
Now that you have built OpenFOAM (hopefully 64 bit version) on sgi, you can run "foamInstallationTest" to check the installation.

If it's working, it would be great if you provide the binaries so that anyone else can use it. You can use 'foamPackBin' which will pack all the sgi64 libraries and executables and send it to Mattijs so that he puts the binaries on the web and any new 'sgi' user prays for you because of that:D.

Something like

foamPackBin sgi64GccOpt

Look at this thread. Jason has done similar thing for Solaris.

http://www.cfd-online.com/OpenFOAM_D...tml?1105108934

Thanks.

Hi porters,

short explanation about the machine string:

sgi64GccOpt

(the $WM_OPTIONS variable) is the sum of the different build options
- architecture ('sgi64')
- compiler (usually empty except if non-system compiler used)
- compilation options ('Opt', 'Debug' or 'Prof')

All machine dependent files are put in subdirectories with this name (e.g. $FOAM_APPBIN) so you can run a single installation with multiple architectures (over here we run 64bit (AMD) and 32bit from the same installation)

Mattijs

I've recompiled OpenFOAM using the following intel compilers:

1. 8.1.026 build 20041123
2. 8.1.022 build 20040922
3. 8.0.066 build 20040416
4. GCC 3.4.3 built from sources</LI>

on our Itanium2 system with a Debian derived system build. The results are:

1. Builds fine using the options I've earlier submitted to this list. icoFoam tutorial works, but interFoam and rasInterFoam fail as reported earlier
2. Builds fine using the same options as above. Shows the same failure in interFoam and rasInterFoam
3. This release does not build OpenFOAM and is earlier than the version used when you built on the Altix system. This is certain since the options in the distribution are not compatible with this release
4. This built a version that passes the interFoam and rasInterFoam tutorial.</LI>

It would be interesting to know the version you used to build with on the Altix and also if possible other details (such as what GNUC version was installed at the time).
/Nils

I have checked through my Emails and I think the last version I used was:

Version 8.1 Build 20040922 Package ID: l_cc_pc_8.1.022

but they are now upto

Version 8.1 Build 20041123 Package ID: l_cc_pc_8.1.026

but I have never tried it. I don't know what gcc version was installed before I installed

Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)


At some point I will see if I can get access to the SGI again to port OpenFOAM and check the running of interFoam etc. but I don't really think it is worth much effort given that gcc is more reliable than the Intel compiler and the executables a very nearly as fast.

Nils,

Do you get the problem running interFoam even if you compile without optimisation?

It fails even in debug mode, but not in exactly the same way:

cat LOGS/icc-latest-debug-interfoam
[...]
Exec : interFoam . damBreak
Date : Jan 25 2005
Time : 15:08:38
Host : h05n21.pdc.kth.se
PID : 21358
Root : /afs/pdc.kth.se/home/s/smeds/OpenFOAM/smeds-1.0.2/run/tutorials/interFoam
Case : damBreak
Nprocs : 1
Create database

Create mesh

Selecting movingFvMesh staticFvMesh


--> FOAM FATAL ERROR : Cannot find file "points" in directory "constant/polyMesh"

Function: database::findDir(const word& dir, const word& name)
in file: db/database/findDir.C at line: 135.

FOAM exiting


cat LOGS/icc-latest-opt-interfoam
[...]
Exec : interFoam . damBreak
Date : Jan 25 2005
Time : 15:11:52
Host : h05n21.pdc.kth.se
PID : 21962
Root : /afs/pdc.kth.se/home/s/smeds/OpenFOAM/smeds-1.0.2/run/tutorials/interFoam
Case : damBreak
Nprocs : 1
Create database

Create mesh

Selecting movingFvMesh staticFvMesh

Reading environmentalProperties
Reading field pd

Reading field gamma

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Calculating field g.h


Max Courant Number = 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0

Starting time loop


Max Courant Number = 0
deltaT = 0.00192308
Time = 0.00192308

Liquid phase volume fraction = 0.119821 Min(gamma) = 0 Max(gamma) = 1
Liquid phase volume fraction = 0.119821 Min(gamma) = 0 Max(gamma) = 1
Liquid phase volume fraction = 0.119821 Min(gamma) = 0 Max(gamma) = 1
Liquid phase volume fraction = 0.119821 Min(gamma) = 0 Max(gamma) = 1
ICCG: Solving for pd, Initial residual = 1, Final residual = 7.90876e-11, No Iterations 83
ICCG: Solving for pd, Initial residual = 2.82359e-05, Final residual = 9.06376e-11, No Iterations 67


--> FOAM FATAL ERROR :
request for surfaceScalarField phi from objectRegistry failed
available objects of type surfaceScalarField are

9
(
interpolate(gh)
muEff
meshPhi_0
UBlendingFactor
interpolate(gamma)
((interpolate(grad(gamma))|(mag(interpolate(grad(g amma)))+deltaN))&S)
((interpolate(gamma)*rho)+((1-interpolate(gamma))*rho))
rho*phi
(rho|A(U))
)


Function: objectRegistry::lookupObject(const word&)
in file: /afs/pdc.kth.se/home/s/smeds/OpenFOAM/OpenFOAM-1.0.2/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line: 166.

FOAM aborting

The behaviour you are getting in debug mode is very strange indeed, it appears to think the mesh hasn't been constructed.

I have a possible work-around for the problem you see with optimisation. Try replacing

surfaceScalarField phiU = phi;

with

surfaceScalarField phiU("phiU", phi);

in OpenFOAM-1.0.2/applications/solvers/multiphase/interFoam/rhoUp/pEqn.H

and

OpenFOAM-1.0.2/applications/solvers/multiphase/interFoam/Up/pEqn.H

and recompile.

I'll try your suggestion and report back by the end of the week.

/Nils

Henry,

Your suggested changes to
OpenFOAM-1.0.2/applications/solvers/multiphase/interFoam/rhoUp/pEqn.H
OpenFOAM-1.0.2/applications/solvers/multiphase/interFoam/Up/pEqn.H
were sufficient to make the interFoam and rasInterFoam examples to run to completion. Thanks!

I'll start new clean re-builds to check to verify my build procedure and then report the complete set of changes I made to make it compile and run in my environment.

/Nils

[ali]

For a multiprocessor, running IRIX6.5, I have OpenFOAM1.0.2 installed.

1) I guess this version should use LAM for parallel runs, right?

2)When I wanted to run it using LAM/MPI, I created a script for submitting to PBS, and used the commands (lamboot, lamexec ...) as explained in User guide, but I got errors like:

/usr/spool/PBS/mom_priv/jobs/69460.nexus.SC: line 14: lamboot: command not found
/usr/spool/PBS/mom_priv/jobs/69460.nexus.SC: line 16: lamexec: command not found
/usr/spool/PBS/mom_priv/jobs/69460.nexus.SC: line 18: lamhalt: command not found

While I didn't get such error with another multi-processor running linux, when I compared their "lam7.1.1" drectories, the IRIX machine, does not have "platforms" directory.

> dir
AUTHORS INSTALL Makefile.am README acinclude.m4 config configure.in etc man romio tools
HISTORY LICENSE Makefile.in VERSION aclocal.m4 configure doc examples otb share

How do I get this problem solved? Does it have anything to do with correct installation of "OpenFOAM-1.0.2.sgiN32GccOpt.tgz"?

[henry]

On IRIX machines you should use SGI's version of MPI not LAM and by default OpenFOAM is setup to compile with it. For information on how to use SGI's version of MPI consult their documentation.

[ali]

I had guessed that, but still got many problems. I think MPI is already installed on this machine,

% which mpirun
/usr/bin/mpirun

Do I need to re-install it or change any setting?


I used mpirun in my This is the PBS script:

/usr/bin/mpirun -np 2 $HOME/OpenFOAM/OpenFOAM-1.0.2/applications/bin/sgiN32GccOpt/icoFoam $HOME/OpenFOAM/ali/run/tutorials/icoFoam cavity -parallel

But it stops without running and the error files contains this:

MPI: could not run executable
MPI: No details available, no log files found (all_signal.c:203)



I have also checked


% ldd `which icoFoam`
libPstream.so => /site/home/ali/OpenFOAM/OpenFOAM-1.0.2/lib/sgiN32GccOpt/dummy/libPstream.so
libOpenFOAM.so => /site/home/ali/OpenFOAM/OpenFOAM-1.0.2/lib/sgiN32GccOpt/libOpenFOAM.so
libfpe.so => /usr/lib32/libfpe.so
libstdc++.so.7 => /site/home/ali/OpenFOAM/sgiN32/gcc-3.4.3/lib/libstdc++.so.7
libm.so => /usr/lib32/libm.so
libgcc_s.so.1 => /site/home/ali/OpenFOAM/sgiN32/gcc-3.4.3/lib/libgcc_s.so.1
libc.so.1 => /usr/lib32/libc.so.1
libfoamUser.so => /site/home/ali/OpenFOAM/OpenFOAM-1.0.2/lib/sgiN32GccOpt/libfoamUser.so
1252945:/site/home/ali/OpenFOAM/OpenFOAM-1.0.2/applications/bin/sgiN32GccOpt/ico Foam: rld: Warning: elfmap: running 32-bit executable but finding 64-bit shared objects /usr/global/express6.2/lib/sg6/libz.so in the search path. You may not have set the environment variables correctly, please set LD_LIBRARY_PATH for old 32-bit objects, LD_LIBRARYN32_PATH for new 32-bit objects and LD_LIBRARY64_PATH for 64-bit objects (e_ident[EI_CLASS] 2) -- continue searching ...
libz.so => /site/home/ali/OpenFOAM/OpenFOAM-1.0.2/lib/sgiN32GccOpt/libz.so


Do I need to change the settings of $HOME/.OpenFOAM/bashrc and mabi=32 or mabi=64?

[henry]

It looks like your LD_LIBRARY... environment variables are not setup correctly which can be a bit tricky on the IRIX OS but was made easier on the most recent releases. Contact your admin people to get help with these settings.

[ali]

Should I see this when I type:

> which mpirun
/usr/bin/mpirun

or it should point to a directory inside OpenFOAM?

May it bebecause I have 32bit version of OpenFOAM, but the machine is setup for 64bit ???

[mattijs]

Is anyone running myrinet?

I'm trying to run on myrinet with mpich+gm and get the error:

"Malloc hook test failed: the malloc provided by MPICH-GM is not used, it may have been overloaded by a malloc provided by another library"

Anyone have something similar? This is on an opteron system (ibm e325) running 64bit OpenFOAM.

[mbeaudoin]

Hello Mattijs,

I have the exact same problem on my cluster (x86).

All I know right now is that MPICH-GM is using it's own version of malloc, and there is a clash somewhere with some module from OpenFOAM + the standard malloc.

I am still hunting that one down, I will keep you posted as soon as I find something.

Martin

[mattijs]

Solution seems to be to have -L$(FOAM_MPI_LIBBIN) -lPstream as final argument on the link line of the applications (e.g. icoFoam)

This enforces the GM malloc to be used.

Still trying to find out how to include it into the wmake system.

[dhebert]

I am trying to compile OpenFOAM 1.3 on an SGI IA64/Altix system (supercomputing system). I noticed that the compiler uses icc with the flag gcc-version-330. Everything I've been reading says OpenFOAM need gcc version 3.4 or higher (perferable 4.1). Two Questions:

1) is the gcc-version flag necessary?

2) Does this mean that I should get the latest gcc and install in my local directory, then compile OpenFoam 1.3?

Thanks for your help,

David

[jens_klostermann]

Hi David,

I compiled OpenFOAM (Hrv's version) on on an SGI IA64/Altix system (using as well as lam as openmpi for mpi) using Intel Compiler Version 9.0. on RedHatLinux Enterprise. As far as I can remember gcc version didn't mater (we have only gcc 3.2.3 installed on our Altix)

So from my point of view:

@1) no

@2) no

Jens

[dhebert]

Jens,

Thanks so much for the information! I have a few more questions if you don't mind...

1) I am a little confused on your mpi definition. Did you use lam or openmpi or mpi for $WM_MPLIB?

2) Did you recieve the following optimation warning? (and what to do about it?)

warning #1357: ptimization disabled due to excessive resource requirements?


3)Did the initial compilation take a REALLY, REALLY long time, (order 6 hours?)

Thanks again, I really appreciate it.

David