2016-12-09 13:33 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000577OpenFOAM[All Projects] Bugpublic2013-09-04 09:24
Reporternogenmyr 
Assigned Touser2 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
PlatformLinuxOSCentOSOS Version5.4
Product Version 
Target VersionFixed in Version 
Summary0000577: spray and dynamic meshes...
DescriptionReferences to
  meshTools::constrainToMeshCentre
  meshTools::constrainDirection

in
  InjectionModel.C
  KinematicParcel.C

seems to cause MPI errors upon parcel injection. Commenting the lines out gives a running code. (hopefully correct for at least 3D cases)
Steps To ReproduceTransform the aachenBomb case into a dynamicMesh case and run with sprayEngineFoam solver in parallel.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0001621

nogenmyr (reporter)

Ok, I've been digging a bit further.

meshTools::constrainToMeshCentre calls for polyMesh::geometricD(), which in turn calls polyMesh::calcDirections() only when there was a mesh update. polyMesh::calcDirections() has in turn a few MPI calls.

During run, not all processors will call constrainToMeshCentre equal amounts of time, which causes a sync problem. (my understanding). A less ugly hack than suggested above would be to let all processors call constrainToMeshCentre the same amount of times, even they do not need it for their own:

In InjectionModel<CloudType>::injectSteadyState that means adding an else-statement:

if (cellI > -1)
{
 .... (unaltered)
}
else
{
   point p(0.,0.,0.);
   Vector<scalar> v(0.,0.,0.);
   meshTools::constrainToMeshCentre(mesh, p);
   meshTools::constrainDirection
   (
      mesh,
      mesh.solutionD(),
      v
   );
}

~0002456

user2

Thanks for the report - fixed by commit 4189687
+Notes

-Issue History
Date Modified Username Field Change
2012-07-09 12:05 nogenmyr New Issue
2012-08-22 09:39 nogenmyr Note Added: 0001621
2013-09-04 09:24 user2 Note Added: 0002456
2013-09-04 09:24 user2 Status new => resolved
2013-09-04 09:24 user2 Fixed in Version => 2.2.x
2013-09-04 09:24 user2 Resolution open => fixed
2013-09-04 09:24 user2 Assigned To => user2
+Issue History