View Issue Details

IDProjectCategoryView StatusLast Update
0002689OpenFOAM[All Projects] Bugpublic2017-11-28 10:26
ReporterThalenberghenAssigned Tohenry 
Status closedResolutionno change required 
PlatformGNU/LinuxOSCentOSOS Version7.3
Product Version5.0 
Fixed in Version 
Summary0002689: Export order of boundaryData different for serial and parallel execution

my goal is to use the surfaces functionObject to export faceCenters to sample another simulation in those locations and use the result as data for a boundary condition.
For this to properly work, the order of the faces has to match, so that the boundary data isn't scrambled all over the patch.
This works fine if I export the locations in serial, however in parallel the order does not match.
Is there a way to enforce the surface writers to keep the correct order in parallel?

Thanks for your help!
Steps To ReproduceUse surfaces functionObject in serial and parallel, the order of the exported data will not match.

I am currently using the "boundaryData" writer, but the same happens for "raw" and others.
Tagsboundary conditions, sample



2017-11-28 10:25

manager   ~0009077

In parallel the surface data is simply collated:

        // Collect values from all processors
        List<Field<Type>> gatheredValues(Pstream::nProcs());
        gatheredValues[Pstream::myProcNo()] = values;

which is done consistently for all of the surface data including faceCenters.

However the data will not have the same order for other decompositions or running in serial.

If you need the data to have the same order as a serial run you will need to reorder it using the maps generated by decomposePar which will be quite complicated.


2017-11-28 10:26

manager   ~0009078

> Export order of boundaryData different for serial and parallel execution

That is correct.

Issue History

Date Modified Username Field Change
2017-09-06 10:56 Thalenberghen New Issue
2017-09-20 09:28 Thalenberghen Tag Attached: boundary conditions
2017-09-20 09:28 Thalenberghen Tag Attached: sample
2017-11-28 10:25 henry Note Added: 0009077
2017-11-28 10:26 henry Assigned To => henry
2017-11-28 10:26 henry Status new => closed
2017-11-28 10:26 henry Resolution open => no change required
2017-11-28 10:26 henry Note Added: 0009078