View Issue Details

IDProjectCategoryView StatusLast Update
0001130OpenFOAM[All Projects] Bugpublic2018-11-23 12:22
Reporteruser588Assigned Touser4 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSOtherOS Version(please specify)
Product Version 
Fixed in Version 
Summary0001130: IOerror and garbage in boundary fields with redistributePar
DescriptionI have found a couple of problems when using redistributePar. This is tested in 2.2.2.
 
I have reproduced it in the attached modified version of the cavity case. It has flow-through sides, as the problems with the fields defintely happens on inletOutlet/outletInlet patches. Other types I'm not sure about.

Unpack the attached and run:
 
    cp system/controlDict.probes system/controlDict
    blockMesh
    cp system/decomposeParDict.4 system/decomposeParDict
    decomposePar
 
Running redistributePar to move from 4 to 3 processors gives an error:
 
    cp system/decomposeParDict.3 system/decomposeParDict
    mpirun -np 4 redistributePar -parallel
 
    [2]
    [2]
    [2] --> FOAM FATAL IO ERROR:
    [2] error in IOstream "IOstream" for operation operator>>(Istream&, List<T>&) : reading first token
    [2]
    [2] file: IOstream at line 0.
    [2]
    [2] From function IOstream::fatalCheck(const char*) const
    [2] in file db/IOstreams/IOstreams/IOstream.C at line 114.
    [2]
    FOAM parallel run exiting
    [2]
 
The error is associated with the presence of the 'probes' function object,
i.e. commenting it out:
 
    cp system/controlDict.noProbes system/controlDict
    mpirun -np 4 redistributePar -parallel
 
works, but there is garbage in the boundary fields, looking as though it is
uninitialised data. It is hard to catch them with this small test case, but
with real cases the fields (scalar fields in particular) have NaNs in them.
TagsNo tags attached.

Activities

user588

2014-01-09 13:44

 

cavity_redistributePar_bug_20140109.tar.bz2 (2,237 bytes)

user4

2014-01-09 15:23

  ~0002755

Fixed the probes functionObject problem in:

2830a4302711560e9772dd40e85cf1cbb10a85fe
f44f192e9db4894b832c38001f0a1f7ec3bbc946

Try having a dummy patch with zeroGradient just before the processor patches (it uses the last non-processor patch for extracting fields to send over)

user4

2014-01-09 16:35

  ~0002756

Resolved in 6c399a448855e18d335202434b4304203de65eef

Issue History

Date Modified Username Field Change
2014-01-09 13:44 user588 New Issue
2014-01-09 13:44 user588 File Added: cavity_redistributePar_bug_20140109.tar.bz2
2014-01-09 15:23 user4 Note Added: 0002755
2014-01-09 16:35 user4 Note Added: 0002756
2014-01-09 16:35 user4 Status new => resolved
2014-01-09 16:35 user4 Fixed in Version => 2.2.x
2014-01-09 16:35 user4 Resolution open => fixed
2014-01-09 16:35 user4 Assigned To => user4