CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Installation

Truncated terminal output using 'Run-time Code Compilation in parallel'

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By SD@TUB

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   March 5, 2014, 08:15
Default Truncated terminal output using 'Run-time Code Compilation in parallel'
  #1
Member
 
Stefan
Join Date: Jan 2010
Location: Kiel, Germany
Posts: 81
Rep Power: 16
SD@TUB is on a distinguished road
Hi FOAMers,

I am working on Debian Squeeze (x64). Since version 2.2.x I need to install OF via
Code:
foamCompiler=ThirdParty
option because of minimum requirement for the compiler gcc.
Compilation went smooth, foamInstallationTest reports:
Code:
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:
Code:
 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?
Code:
[: 460: -lt: unexpected operator
[: 460: -gt: unexpected operator
[: 460: -lt: unexpected operator
[: 460: -gt: unexpected operator
[: 460: !=: unexpected operator
Thanks
/Stefan
SD@TUB is offline   Reply With Quote

Old   March 6, 2014, 16:54
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
__________________

Last edited by wyldckat; March 6, 2014 at 16:55. Reason: see "edit:"
wyldckat is offline   Reply With Quote

Old   March 7, 2014, 07:51
Default
  #3
Member
 
Stefan
Join Date: Jan 2010
Location: Kiel, Germany
Posts: 81
Rep Power: 16
SD@TUB is on a distinguished road
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
Attached Files
File Type: gz motorBike.tar.gz (8.5 KB, 2 views)

Last edited by SD@TUB; March 11, 2014 at 08:12.
SD@TUB is offline   Reply With Quote

Old   March 23, 2014, 14:17
Default
  #4
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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:
    Code:
    [...] 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
__________________
wyldckat is offline   Reply With Quote

Old   April 15, 2014, 15:28
Default Solved
  #5
Member
 
Stefan
Join Date: Jan 2010
Location: Kiel, Germany
Posts: 81
Rep Power: 16
SD@TUB is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
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
wyldckat likes this.
SD@TUB is offline   Reply With Quote

Reply

Tags
dynamiccode, truncated output

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Sudden jump in Courant number NJG OpenFOAM Running, Solving & CFD 7 May 15, 2014 14:52
Cannot run the code in parallel. Help please (urgent). crst15 OpenFOAM 11 February 17, 2014 02:02
How to make code run in parallel? cwang5 OpenFOAM Programming & Development 1 May 30, 2011 05:47
lift and drag on ship superstructures vaina74 OpenFOAM Running, Solving & CFD 3 June 8, 2010 13:30
Design Integration with CFD? John C. Chien Main CFD Forum 19 May 17, 2001 16:56


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