View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000301OpenFOAMBugpublic2011-09-29 15:412011-10-25 15:40
Reporteruser262Assigned Touser4 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformCore i7OSLinux x86_64OS Version2.6.29
Summary0000301: OpenFOAM does not run in parallel mode on Core i7
DescriptionWhen I try to run OpenFOAM in parallel mode on my Core i7 (8GB of RAM) with command

mpirun -np 4 interFoam -parallel

I get this message:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.0.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/

Build  : 2.0.1
Exec   : interFoam -parallel
Date   : Sep 28 2011
Time   : 14:10:42
Host   : 5101-5
PID    : 19154
Case   : /home/roman/OpenFOAM/roman-2.0.1/run/damBreak
nProcs : 4
Slaves :
3
(
5101-5.19155
5101-5.19156
5101-5.19157
)

Pstream initialized with:
    floatTransfer     : 0
    nProcsSimpleSum   : 0
    commsType         : nonBlocking
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] ill defined primitiveEntry starting at keyword 'slaves' on line 0 and ending at line 3
[0]
[0] file: IStringStream.sourceFile at line 3.
[0]
[0]     From function primitiveEntry::readEntry(const dictionary&, Istream&)
[0]     in file db/dictionary/primitiveEntry/primitiveEntryIO.C at line 165.
[0]
FOAM parallel run exiting
[0]

--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun has exited due to process rank 0 with PID 19154 on
node 5101-5 exiting improperly. There are two reasons this could occur:

1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.

2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"

This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------

OpenFOAM was built with gcc-4.5.2
TagsNo tags attached.

Activities

user4

2011-09-30 11:16

  ~0000674

Most likely your problem is your machine names - OpenFOAM expects them to be valid 'words' so to start with alphabetic characters.

wyldckat

2011-10-01 23:37

updater   ~0000676

Last edited: 2011-10-01 23:39

 I've confirmed in a virtual machine that the following names:
* 5101-5 - gives the very same error as reported;
* 51015 - runs without problems;
* 5101_5 - runs without problems;
* 5101s-5 - runs without problems;
* 5101-s5 - gives the very same error as reported;
* 5101_-s5 - runs without problems.

So... only a number followed by a dash is a big "no no"!?

Can there be an exception added to OpenFOAM for both username and hostname string validation? Because I've seen in the past someone on a XtreemOS cluster/grid, who had a username based on a _crazy_ "globally unique identifier" (GUID).
Ah, here it is: http://www.cfd-online.com/Forums/openfoam-installation/79535-moving-already-installed-openfoam-different-machine-user.html

I think this is rather uncommon, but since the world is stepping into the cloud computing and IPv6 era, perhaps further "future proofing" would be a nice tweak for OpenFOAM's core ;)

edit: see Issue #298, where such an exception flag would also be helpful for chemical name species!

user262

2011-10-04 11:09

  ~0000678

Thank you very much! Problem was fixed!

user4

2011-10-06 14:57

 

stringUser.tgz (17,325 bytes)

user4

2011-10-06 15:00

  ~0000691

Hi wyldcat,

is it easy for you to try attached stringUser.tgz? They are replacements for 20x to have strings for userName,hostName,domainName in OSspecific.

wyldckat

2011-10-06 15:05

updater   ~0000692

Hi Mattijs,

Yes it should be pretty easy, so I'll try it later today or this weekend. I'll keep you posted!

By the way, have you checked Issue #298 as well? It's a similar problem to this one, but my guess is that the solution is going to have to be a bit different from this one...

wyldckat

2011-10-09 16:11

updater   ~0000706

Hello Mattijs,

I've finished testing in 2 VMs with Ubuntu 11.04 with:
* 5101-5 and 5101-6 for each hostname;
* username 5101-5 on both VMs.

Tested running in parallel in a single VM and with the two VMs with parallel communications between them. I've confirmed that the "stringUser.tgz" replacements worked well. Also confirmed that the .deb version 2.0.1 didn't work under these conditions, therefore this seems to verify that the modifications did work.
Also ran "blockMesh" in serial, to check if it still worked and it did.

By the way, OpenFOAM 2.0 doesn't seem to have any problems with "crazy" usernames, since it seems to only use the username for log keeping. Therefore, it didn't seem necessary to define the username as string... but since I don't have access to an XtreemOS cluster/grid installation, I can't confirm this.
Said "crazy" names that I tested were: the same GUID name on the other thread I posted before and with the same name as the machine's "5101-5".

As for the domainName, I didn't find any "ready to use" test to be done to it... it isn't even used by "src/OpenFOAM/global/argList/argList.C".
But I suppose this way it's "future proof" :)

Best regards,
Bruno

user4

2011-10-25 15:39

  ~0000752

Hi Bruno,

thanks for testing. This change will be in the next version. Not sure about putting it in 20x but people can apply the change themselves.

user4

2011-10-25 15:40

  ~0000753

fixed in next version under 81b5184b9fd4899976db92e89944708b2c7d8d8f

Issue History

Date Modified Username Field Change
2011-09-29 15:41 user262 New Issue
2011-09-30 11:16 user4 Note Added: 0000674
2011-10-01 23:37 wyldckat Note Added: 0000676
2011-10-01 23:39 wyldckat Note Edited: 0000676
2011-10-04 11:09 user262 Note Added: 0000678
2011-10-06 14:57 user4 File Added: stringUser.tgz
2011-10-06 15:00 user4 Note Added: 0000691
2011-10-06 15:05 wyldckat Note Added: 0000692
2011-10-09 16:11 wyldckat Note Added: 0000706
2011-10-25 15:39 user4 Note Added: 0000752
2011-10-25 15:40 user4 Note Added: 0000753
2011-10-25 15:40 user4 Status new => resolved
2011-10-25 15:40 user4 Fixed in Version => Other
2011-10-25 15:40 user4 Resolution open => fixed
2011-10-25 15:40 user4 Assigned To => user4