View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000619OpenFOAMBugpublic2012-08-08 08:122015-02-06 09:07
Reportertjkulju Assigned Touser4 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSCentOSOS Version5.8
Summary0000619: redistributePar produces nan
DescriptionI'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 Reproduce1. redistributePar (with ptscotch)
2. grep nan processor*/*
Tagsparallel, redistributePar

Activities

user4

2012-08-08 10:24

  ~0001572

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.

tjkulju

2012-08-08 11:15

reporter   ~0001574

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.

user797

2013-11-13 08:04

  ~0002627

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

wyldckat

2013-11-13 14:41

updater   ~0002629

@f8kuniie: Can you provide a simple test case that demonstrates this issue?

user797

2013-11-14 00:50

  ~0002634

Hello wyidckat.

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.

https://www.hightail.com/download/OGhmYUl1d0F6RTlYd3NUQw

henry

2015-02-05 10:08

manager   ~0003687

Could you test redistributePar in OpenFOAM-2.3.x?

wyldckat

2015-02-05 22:18

updater   ~0003703

Last edited: 2015-02-05 22:18

 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 fixedValueFvPatchField<Type>&,
        const fvPatch&,
        const DimensionedField<Type, volMesh>&,
        const fvPatchFieldMapper&
    )

        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?

wyldckat

2015-02-05 22:19

updater  

log.redistributePar (20,491 bytes)

user4

2015-02-06 09:05

  ~0003704

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.

user4

2015-02-06 09:07

  ~0003705

thanks for reporting & testing

Issue History

Date Modified Username Field Change
2012-08-08 08:12 tjkulju New Issue
2012-08-08 10:24 user4 Note Added: 0001572
2012-08-08 11:15 tjkulju Note Added: 0001574
2013-11-13 07:54 user797 Tag Attached: parallel
2013-11-13 07:54 user797 Tag Attached: redistributePar
2013-11-13 08:04 user797 Note Added: 0002627
2013-11-13 14:41 wyldckat Note Added: 0002629
2013-11-14 00:50 user797 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
2015-02-05 22:19 wyldckat File Added: log.redistributePar
2015-02-06 09:05 user4 Note Added: 0003704
2015-02-06 09:07 user4 Note Added: 0003705
2015-02-06 09:07 user4 Status new => resolved
2015-02-06 09:07 user4 Fixed in Version => 2.3.1
2015-02-06 09:07 user4 Resolution open => fixed
2015-02-06 09:07 user4 Assigned To => user4