2017-12-15 23:42 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002772OpenFOAM[All Projects] Bugpublic2017-11-29 12:50
Reporterslanth 
Assigned Towill 
PriorityurgentSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version12.04
Product Versiondev 
Target VersionFixed in Version5.x 
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
Tagsspray
Attached Files

-Relationships
+Relationships

-Notes

~0009084

will (manager)

Last edited: 2017-11-28 14:46

View 2 revisions

Reproduced.

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.

~0009085

slanth (reporter)

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()?

~0009086

will (manager)

Last edited: 2017-11-28 16:05

View 2 revisions

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 http://en.cppreference.com/w/cpp/numeric/random) 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

~0009105

will (manager)

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.
+Notes

-Issue History
Date Modified Username Field Change
2017-11-28 02:15 slanth New Issue
2017-11-28 02:15 slanth File Added: aachenBomb.zip
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 View Revisions
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 View Revisions
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
+Issue History