View Issue Details

IDProjectCategoryView StatusLast Update
0001791OpenFOAMBugpublic2015-07-27 09:02
Reporteruser1187Assigned Tohenry  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Summary0001791: cell, tetFace and tetPt search failure while reconstructing fields for reconstructPar (MPPICFoam)
DescriptionI am using the MPPICFoam to run a simple case: a pipe with one inlet one outlet and a wall. The solver seems to be solving the necessary 'kinematic cloud' however, when i try to reconstruct the results using reconstructPar (for post-processing) I get the following error -

Reconstructing lagrangian fields for cloud kinematicCloud
--> FOAM FATAL ERROR:
    cell, tetFace and tetPt search failure at position (0.0402328226062 2.6948362608 -0.189881043095)
    for requested cell 95279
    If this is a restart or reconstruction/decomposition etc. it is likely that the write precision is not sufficient.
    Either increase 'writePrecision' or set 'writeFormat' to 'binary'
    From function void Foam::particle::initCellFacePt()
    in file /home/me/OpenFOAM/OpenFOAM-2.4.0/src/lagrangian/basic/lnInclude/particleI.H at line 758.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::reconstructLagrangianPositions(Foam::polyMesh const&, Foam::word const&, Foam::PtrList<Foam::fvMesh> const&, Foam::PtrList<Foam::IOList<int> > const&, Foam::PtrList<Foam::IOList<int> > const&) at ??:?
#3 ? at ??:?
#4 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#5 ? at ??:?
Aborted (core dumped)
Steps To Reproduce1) Download the tarball with the complete case (0/ constant/ system/) (I WAS NOT ABLE TO ATTACH IT; IT IS ABOUT 13Mb, please allow me to upload it in some way)
2) Prepare the case to be run in parallel launching decomposePar
3) Launch MPPICFoam as usual: runParallel MPPICFoam 4
4) When it reaches time of simulation = 0.15 it can be stopped and
5) Run reconstructPar
Additional Information1) I tried both writing precision 12 and binary files
2) As long as I don't make particle injection (i.e. just LES simulation) the problem does not appear
3) it is possible to visualize the solution opening the decomposed case with paraview selecting appropriate flag during opening BUT
THE MAIN PROBLEM IS THAT THIS BUG MAKES RESTART NOT POSSIBLE.
Tagsinjection, Lagrangian, parallel, reconstructPar

Activities

user1187

2015-07-21 09:02

  ~0005102

I uploaded the tarball via Google Drive: https://drive.google.com/file/d/0B5d2Yx1NhFs6U1hXV0NhT1YxeDg/view?usp=sharing

will

2015-07-21 10:10

manager   ~0005104

The location is certainly outside the mesh, so it's probably a sub-model generating a huge non-physical velocity. Combined with the tracking tolerance, this can leave the particle outside the mesh.

Your inlet injection is quite dense, about 32% particulate by volume, and you don't have enough parcels per cell for a reliable MPPIC average. You have about 7.5 parcels in the smallest cell at a packed condition. You need at least 40 for things to be stable. My guess is that the packing model is diverging.

By my reckoning, you should increase parcelsPerSecond to at least 6000000 to make the averaging work properly.

user1187

2015-07-21 10:25

  ~0005105

Last edited: 2015-07-21 10:26

Will, thanks a lot for your answer and for taking care of this issue.

Yes the injection is quite dense, I do not understand which parameter you are looking at when you talk abound "parcels per cell" for a reliable MPPIC average.

You say it is about 7.5 parcel in the smallest cell.

Is it a value that you calculated by yourself taking a look at the mesh or it is the value plotted in the log file named "Min dense number of parcels"?

Because in the latter case (value in the log file) this parameter is constantly growing as the simulation continues, in fact right now, after 1 second of time simulation, it has reached the value of 70.44.

In case the parameter you mentioned was not that one, where can I find/calculate it?

will

2015-07-21 11:15

manager   ~0005106

"Min dense number of parcels" is the number of parcels in the smallest cell. 70.44 at 1 second sounds fine, but it's instantaneous values, in general, that we have to worry about. If "Max cell volume fraction" is approximately the close packed value and "Min dense number of parcels" is less than 40, then we might be concerned.

7.5 is a theoretical value, based on the volume of your parcels and the smallest cell in the mesh. E.g. (matlab/octave syntax)

massFlowRate = 40
particleDiameter = 1.5e-3
inletArea = 0.0519627824419
smallestCellVolume = 4.1855066925e-07
inletVelocity = 2
parcelsPerSecond = 1e6
density = 1201
packedAlpha = 0.6

volumetricFlowRate = massFlowRate/density
inletAlpha = volumetricFlowRate/(inletVelocity*inletArea)

particleVolume = (4/3)*pi*(particleDiameter/2)^3
particlesPerSecond = volumetricFlowRate/particleVolume
particlesPerParcel = particlesPerSecond/parcelsPerSecond
particlesPerSmallestCell = packedAlpha*smallestCellVolume/particleVolume
parcelsPerSmallestCell = particlesPerSmallestCell/particlesPerParcel

user1187

2015-07-21 12:23

  ~0005108

Will, thanks a lot for your support.

It is quite clear now.

I was just wondering: this would mean that, given all other parameters, if I need to refine the mesh (lets say I need that to improve eulerian field solution accuracy) I also need to increase the number of parcels per second?

What if at some point in the process the number of parcels equals the number of particles? Is that a limit for this type of simulation? I.e. the point when the number of parcels is increased to assure 40 parcels minimum in the smallest cell and it reaches the number of particles.

Thanks again for your work.

Blue skies.
Alex

will

2015-07-21 15:43

manager   ~0005113

Yes, you are right on both counts. If you refine your mesh, you will need to increase the number of parcels accordingly. You obviously can't increase the number of parcels beyond a single particle per parcel, so this is the limit of resolution possible with MPPIC. A reliable average can't be calculated on smaller cells, as not enough particles can fit in the volume. If your cells get this small relative to the particles, then you need DPMFoam.

user1187

2015-07-21 15:49

  ~0005114

Great. Everything makes sense now. Thanks again.

Cheers.

will

2015-07-21 16:03

manager   ~0005115

Whilst this has been a useful exercise in documenting the setup of MPPIC cases, I've now actually run the case, and I don't get the error. It was set-up for 2.3, and I ran a month-ish old 2.3.x. Maybe try updating, if your version is older. There have been some recent bug fixes to patch injection which might have affected this case. Your mesh is also castellated, which is odd. There are quite a lot of faces sitting perpendicular to the flow of particles which are likely to pack rapidly and cause problems. Why aren't you using a mesh which conforms to the geometry?

user1187

2015-07-21 16:15

  ~0005116

Last edited: 2015-07-21 21:57

I think I have the lastest version, I am quite sure, but I will try to update just in case.

About the mesh, I started with a conforming mesh, but with my meshing tool (not snappy) to have a conforming mesh I have a mesh with only tetrahedral cells, and with that cells I was getting only divergence, I think it is something related with non orthogonality (quite high with tetra), can you confirm that? In this case I was thinking a solution can be to add dumping on parcels kinematic setting, I am not sure how to do that, but I think I found something online. Have you any advice?

So I tried a very basic hexa mesh to rule out non orthogonal cells, but as you noticed it is non body conforming. Since it was looking good on the convergence side, I left the conforming mesh for later and focused on this problem.

will

2015-07-22 09:30

manager   ~0005121

It's entirely plausible that your tet mesh has too much non-orthogonality, but it could be any number of other things, too. I don't know what you mean by "dumping on parcels kinematic setting". This isn't a forum on which to provide support for your case setup; I'm just trying to ascertain whether there is a bug or not.

Interestingly, I have now run the case with a completely up to date 2.3.x, and I an reproduce the error. It looks like something has changed in the last couple of months which is causing this case to fail. I'll roll it back and see if I can find the change.

user1187

2015-07-22 09:34

  ~0005122

OK, I was almost sure I was using the lastest version.

With "adding dumping" I meant using "dampingModel" feature of constant/kinematicCloudProperties file.

But maybe other mesh features are involved in my divergence on TET mesh. Anyway thanks for you support.

henry

2015-07-23 08:28

manager   ~0005124

User support

Issue History

Date Modified Username Field Change
2015-07-21 00:30 user1187 New Issue
2015-07-21 08:57 user1187 Tag Attached: Lagrangian
2015-07-21 08:57 user1187 Tag Attached: parallel
2015-07-21 08:57 user1187 Tag Attached: injection
2015-07-21 08:57 user1187 Tag Attached: reconstructPar
2015-07-21 09:02 user1187 Note Added: 0005102
2015-07-21 10:10 will Note Added: 0005104
2015-07-21 10:25 user1187 Note Added: 0005105
2015-07-21 10:26 user1187 Note Edited: 0005105
2015-07-21 11:15 will Note Added: 0005106
2015-07-21 12:23 user1187 Note Added: 0005108
2015-07-21 15:43 will Note Added: 0005113
2015-07-21 15:49 user1187 Note Added: 0005114
2015-07-21 16:03 will Note Added: 0005115
2015-07-21 16:15 user1187 Note Added: 0005116
2015-07-21 18:01 user1187 Note Edited: 0005116
2015-07-21 21:57 user1187 Note Edited: 0005116
2015-07-22 09:30 will Note Added: 0005121
2015-07-22 09:34 user1187 Note Added: 0005122
2015-07-23 08:28 henry Note Added: 0005124
2015-07-23 08:28 henry Status new => closed
2015-07-23 08:28 henry Assigned To => henry
2015-07-23 08:28 henry Resolution open => no change required