View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000619||OpenFOAM||[All Projects] Bug||public||2012-08-08 08:12||2015-02-06 09:07|
|Fixed in Version|
|Summary||0000619: redistributePar produces nan|
|Description||I'm running a dynamic mesh refinement case in parallel and after some time when I want redistribute the case to get a better load balancing, I get nan values on some fields. The initial decomposition is done with simple method and the redistribution with ptscotch. If I redistribute with simple, nan values are not produced.|
|Steps To Reproduce||1. redistributePar (with ptscotch)|
2. grep nan processor*/*
Are these 'nan's in the internalField or on one of the processor patch fields? The latter will happen since transferring meshes will cause processor patches to be introduced where there were none before. These don't get a value so will stay unset.
There should be none in the internalField or non-processor patch fields.
The fact that none were appearing with simple might be just that no new processor patches were introduced, they only got different number of faces.
||The 'nan's are in the internalField. In some cases by using the 2.1.0-version, the redistribution seemed to be more close to 'simple'-way (i.e. along y-axis in my case) and everything was fine. But after repeating the procedure few times, the same thing reappeared with that version also.|
I confirmed the similar phenomenon. In my environment, 'nan's are also outputed to other than internalField.
OpenFOAM Version: 2.1.1
OS: CentOS 5.5
||@f8kuniie: Can you provide a simple test case that demonstrates this issue?|
You can download test case from following link.
You can reproduce phenomenon by running "solve" shell script.
In this shell script, The shell-variable "SOLVE_NUM_PROC" is defined whichi specify the number of process.
||Could you test redistributePar in OpenFOAM-2.3.x?|
Fortunately f8kuniie's link still works well! Many thanks for that and for the detailed instructions!
I've tested just now with OpenFOAM 2.1.1 and 2.3.x:
- With OpenFOAM 2.1.1 I was able to reproduce the same bug that f8kuniie reported. I simply had to run:
grep -r -i nan processor*
and easily saw a lot of "nan" entries.
- With OpenFOAM 2.3.x it was able to use redistributePar without creating the weird "nan" and other crazy values.
I believe this issue was very similar to http://www.openfoam.org/mantisbt/view.php?id=1130
But there is a somewhat weird warning for each sub-domain (i.e. 12 times), emitted by redistributePar with 2.3.x:
--> FOAM Warning :
From function fixedValueFvPatchField<Type>::fixedValueFvPatchField
const DimensionedField<Type, volMesh>&,
in file fields/fvPatchFields/basic/fixedValue/fixedValueFvPatchField.C at line 80
On field subsetnuTilda patch terrain patchField fixedValue : mapper does not map all values.
To avoid this warning fully specify the mapping in derived patch fields.
The full log file is attached as "log.redistributePar".
Based on Mattijs' comment on issue #1130, my guess is that this message is related to OpenFOAM having to create its own dummy patch for the redistribution to work properly?
log.redistributePar (20,491 bytes)
|This is a side effect of the way in which redistribution currently is implemented. The bits get added from all processors so temporarily there are unmapped values and this warning is from that intermediate stage.|
|thanks for reporting & testing|
|2012-08-08 08:12||tjkulju||New Issue|
||Note Added: 0001572|
|2012-08-08 11:15||tjkulju||Note Added: 0001574|
||Tag Attached: parallel|
||Tag Attached: redistributePar|
||Note Added: 0002627|
|2013-11-13 14:41||wyldckat||Note Added: 0002629|
||Note Added: 0002634|
|2015-02-05 10:08||henry||Note Added: 0003687|
|2015-02-05 22:18||wyldckat||Note Added: 0003703|
|2015-02-05 22:18||wyldckat||Note Edited: 0003703||View Revisions|
|2015-02-05 22:19||wyldckat||File Added: log.redistributePar|
||Note Added: 0003704|
||Note Added: 0003705|
||Status||new => resolved|
||Fixed in Version||=> 2.3.1|
||Resolution||open => fixed|
||Assigned To||=> user4|