[SD@TUB]

Hi FOAMers,

I am working on Debian Squeeze (x64). Since version 2.2.x I need to install OF via

foamCompiler=ThirdParty

option because of minimum requirement for the compiler gcc.
Compilation went smooth, foamInstallationTest reports:

Checking basic setup...
-------------------------------------------------------------------------------
Shell:              bash
Host:               computer
OS:                 Linux version 2.6.32-5-amd64
-------------------------------------------------------------------------------


Checking main OpenFOAM env variables...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid      Crit
-------------------------------------------------------------------------------
$WM_PROJECT_INST_DIR /prgz/OpenFOAM                           yes       yes
$WM_PROJECT_USER_DIR /storage001/me/usrDev-2.3.x            no        no
$WM_THIRD_PARTY_DIR  /prgz/OpenFOAM/ThirdParty-2.3.x          yes       yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$WM_PROJECT_DIR      /prgz/OpenFOAM/OpenFOAM-2.3.x            yes  yes  yes

$FOAM_APPBIN         ...-2.3.x/platforms/linux64GccDPOpt/bin  yes  yes  yes
$FOAM_SITE_APPBIN    .../2.3.x/platforms/linux64GccDPOpt/bin  no        no
$FOAM_USER_APPBIN    ...-2.3.x/platforms/linux64GccDPOpt/bin  no        no
$WM_DIR              /prgz/OpenFOAM/OpenFOAM-2.3.x/wmake      yes  yes  yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the LD_LIBRARY_PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$FOAM_LIBBIN         ...-2.3.x/platforms/linux64GccDPOpt/lib  yes  yes  yes
$FOAM_SITE_LIBBIN    .../2.3.x/platforms/linux64GccDPOpt/lib  no        no
$FOAM_USER_LIBBIN    ...-2.3.x/platforms/linux64GccDPOpt/lib  no        no
$MPI_ARCH_PATH       ...x/platforms/linux64Gcc/openmpi-1.6.5  yes  yes  yes
-------------------------------------------------------------------------------


Third party software
-------------------------------------------------------------------------------
Software Version   Location 
-------------------------------------------------------------------------------
flex     2.5.37    .../ThirdParty-2.3.x/platforms/linux64/gcc-4.8.2/bin/flex
[: 460: -lt: unexpected operator
[: 460: -gt: unexpected operator
[: 460: -lt: unexpected operator
[: 460: -gt: unexpected operator
[: 460: !=: unexpected operator
gcc                ...M/ThirdParty-2.3.x/platforms/linux64/gcc-4.8.2/bin/gcc
gzip     1.3.12    /bin/gzip                                                
tar      1.23      /bin/tar                                                 
icoFoam  2.3.x     ...M/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/icoFoam
-------------------------------------------------------------------------------


Summary
-------------------------------------------------------------------------------
Base configuration ok.
Critical systems ok.

The solvers running both in serial and parallel mode. But, in parallel cases where I am using the Run-time Code Compilation functionality the terminal output is truncated everytime at line 52:

 31 Pstream initialized with:
 32     floatTransfer      : 0
 33     nProcsSimpleSum    : 0
 34     commsType          : nonBlocking
 35     polling iterations : 0
 36 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
 37 fileModificationChecking : Monitoring run-time modified files using timeStampMaster
 38 allowSystemOperations : Allowing user-supplied system call operations
 39 
 40 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
 41 Create time
 42 
 43 Create mesh for time = 0
 44 
 45 Reading field p
 46 
 47 Reading field U
 48 
 49 Reading/calculating face flux field phi
 50 
 51 Using #calcEntry at line 34 in file "/storage002/daum/runs/cpu/wigley/ms--hullNo03-doubleHullTest/constant/transportProperties"
 52 Using #codeStream with "/storage002/daum/runs/cpu/wigley/ms--hullNo03-doubleHullTest/dynamicCode/platforms/linux64GccDPOpt/lib/libcodeStream_9a1af66df5a41e153af5341b0be9738563cb3a41.so"

although the process keeps running.
Does anyone know why or experienced the same? With version 2.1.x everything is working fine. I guessed that it might be due to OpenMPI, but I tried both the system version and that one provided by ThirdParty with no difference.

The foamInstallationTest-script also outputs the some warning lines, which were discussed somewhere else in this forum. But this should not be related to the problem above, shouldn' it?

[: 460: -lt: unexpected operator
[: 460: -gt: unexpected operator
[: 460: -lt: unexpected operator
[: 460: -gt: unexpected operator
[: 460: !=: unexpected operator

Thanks
/Stefan

[wyldckat]

Greetings Stefan,

I assume that at the beginning of your post, you meant to write "2.3.x" and not "2.2.x", since the script refers to 2.3.x .
A few questions, to help diagnose the problem:

1. What was the exact command you've used to launch in parallel?
2. Did you use Open-MPI that is installed by Debian (aka the "system" one) or the one provided by OpenFOAM?
3. Did you configure the global "controlDict" file to allow certain system operations?
4. Can you reproduce this error with a (modified) tutorial case from OpenFOAM?

edit: I think you can ignore those messages about "unexpected operator". That's probably a bug that came back from the past... and is somewhat irrelevant.

Best regards,
Bruno

[SD@TUB]

Thank you Bruno for taking a look!

I mean since "2.2.x", so it happens with 2.2.x and 2.3.x as well.

1. At my system, every run command based on mpirun show this behavior.
2. Yes, with "system" one in terms of OpenFOAM language I am using Open MPI 1.4.2 provided with Debian Squeeze.
3. Global system controlDict is altered with allowSystemOperations 1;.
4. Please find a modified motorbike tutorial from 2.3.x enclosed. I only changed two files as you will see:
   • 0.0rg/include/initialConditions (calc velocity vector)
   • system/forceCoeffs (use calculated velocity vector)
   The mesh is not included. You should copy the mesh into it. The Allrun-script is commented according to that.

The log output is truncated when using the modified system/forceCoeffs dict above. So the problem might be related to functionObjects!?

Edit: I checked this issue with Debian Wheezy and fresh compiled OF 2.2.x and 2.3.x via foamCompiler=System. It is still not working there. Something within 'Pstream implementation' and OpenMPI must changed from 2.1.x to 2.2.x in my opinion.

/Stefan

[wyldckat]

Hi Stefan,

I finally managed to give a look into this and I've used the latest commit on 2.3.x. Here's what I've gotten:

1. While running patchSummary in parallel, it did seem to lock up in the line that ended with:
   

   [...] libcodeStream_6c2c1a1344ae80252fe47cae5de14b70b9ed65e5.so' is up to date.

   But after a little while, it essentially showed everything at the end of running this utility.
2. Since the codeStream was built when I ran patchSummary in parallel, I did not get a lock-up while running simpleFoam. In addition, this might also have been because I commented out the line for "forceCoeffs" in "controlDict", for all applications, except for simpleFoam. Then, before running this solver, I uncommented this line and it ran without any problems.

Therefore, the trick seemed to be to make sure that the dynamic code is built before the solver is used. In addition, it's possible that a particular bug has been fixed in OpenFOAM 2.3.x... If I'm not mistaken, this was fixed in this commit: https://github.com/OpenFOAM/OpenFOAM...dac2610cfb52a3 - essentially it was fixed 4-6 days after you asked about this here

Best regards,
Bruno

[SD@TUB]

Originally Posted by wyldckat

Therefore, the trick seemed to be to make sure that the dynamic code is built before the solver is used. In addition, it's possible that a particular bug has been fixed in OpenFOAM 2.3.x... If I'm not mistaken, this was fixed in this commit: https://github.com/OpenFOAM/OpenFOAM...dac2610cfb52a3 - essentially it was fixed 4-6 days after you asked about this here

Hi Bruno,

Today, I updated OF with the latest commit and the bug seems to be fixed indeed. So I do not have to rely on your workaround

Thanks,
Stefan