View Issue Details

IDProjectCategoryView StatusLast Update
0002772OpenFOAMBugpublic2017-11-29 12:50
Reporterslanth Assigned Towill  
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version12.04
Product Versiondev 
Summary0002772: SprayDyMFoam gave a wrong parcel distribution as dynamic mesh is used. The parcel distribution is straight aligned
DescriptionI added a dynamicMeshDict in acchenBomb tutorial used for sprayFOAM.

fvMotionSolver is used for dynamic mesh solving. But it turned out that the

parcels are distributed along several straight line. They are not randomly

distributed like the case for static mesh.
Steps To Reproduce1. Download the case file attached here and uncompress
2. Run sprayDyMFoam
3. Use paraview to visualize cloud only



2017-11-28 02:15

reporter (4,947,465 bytes)


2017-11-28 14:46

manager   ~0009084

Last edited: 2017-11-28 14:46


This is a polyMesh update issue. When the mesh moves, the cell tree is rebuilt. The rebuilding code (in polyMesh::cellTree) creates a random number generator class. This seeds the global random number generator with the same value on every time-step, so you are getting the same injection locations every time-step.

The quick solution would be to put the random generator on the polyMesh, and not rebuild it when the mesh changes. A better way would be to utilise the C++11 random number functionality and do away with global-variable-based seeding entirely.


2017-11-28 15:06

reporter   ~0009085

I still cannot understand too much. What do you mean by putting the random generator on the polyMesh or utilising the C++11 random number functionality? This mean I should change the polyMesh class or change the solver after mesh.move() or mesh.update()?


2017-11-28 16:05

manager   ~0009086

Last edited: 2017-11-28 16:05

The issue is that polyMesh::cellTree is creating a local random number generator every time step. To avoid that, we could make the generator a member of the polyMesh class, so that it persists and doesn't need re-generating. That's what I mean by "putting the random generator on the polyMesh". Jargon, sorry. I don't think we should do this.

The C++11 random numbers (see would be a better thing for OpenFOAM's Random and cachedRandom classes to use. They don't use global seeding, so the whole issue goes away. This is a better idea. I think we should do this. It's a bit of work to do properly, though. Not a quick fix.

If you want a very quick fix, then change line 881 of src/OpenFOAM/meshes/polyMesh/polyMesh.C as follows:

    Random rndGen(261782); // <- change this
    static Random rndGen(261782); // <- to this


2017-11-29 12:50

manager   ~0009105

I've made the very quick fix in dev and 5.x for now, as there doesn't seem to be any disadvantage. Commit e0030193 in 5.x and 78338e59 in dev.

I'd still like to do the wrapping of the C++11 STL random library, but it might be a while before there is time.

Issue History

Date Modified Username Field Change
2017-11-28 02:15 slanth New Issue
2017-11-28 02:15 slanth File Added:
2017-11-28 02:15 slanth Tag Attached: spray
2017-11-28 14:46 will Note Added: 0009084
2017-11-28 14:46 will Note Edited: 0009084
2017-11-28 15:06 slanth Note Added: 0009085
2017-11-28 16:05 will Note Added: 0009086
2017-11-28 16:05 will Note Edited: 0009086
2017-11-29 12:50 will Assigned To => will
2017-11-29 12:50 will Status new => resolved
2017-11-29 12:50 will Resolution open => fixed
2017-11-29 12:50 will Fixed in Version => 5.x
2017-11-29 12:50 will Note Added: 0009105