View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002772 | OpenFOAM | Bug | public | 2017-11-28 02:15 | 2017-11-29 12:50 |
| Reporter | slanth | Assigned To | will | ||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 12.04 |
| Product Version | dev | ||||
| Summary | 0002772: SprayDyMFoam gave a wrong parcel distribution as dynamic mesh is used. The parcel distribution is straight aligned | ||||
| Description | I 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 Reproduce | 1. Download the case file attached here and uncompress 2. Run sprayDyMFoam 3. Use paraview to visualize cloud only | ||||
| Tags | spray | ||||
|
|
|
|
|
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. |
|
|
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()? |
|
|
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 |
|
|
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. |
| 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 | |
| 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 |
