View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001791 | OpenFOAM | Bug | public | 2015-07-21 00:30 | 2015-07-27 09:02 |
Reporter | Assigned To | henry | |||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
Summary | 0001791: cell, tetFace and tetPt search failure while reconstructing fields for reconstructPar (MPPICFoam) | ||||
Description | I 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 Reproduce | 1) 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 Information | 1) 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. | ||||
Tags | injection, Lagrangian, parallel, reconstructPar | ||||
|
I uploaded the tarball via Google Drive: https://drive.google.com/file/d/0B5d2Yx1NhFs6U1hXV0NhT1YxeDg/view?usp=sharing |
|
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. |
|
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? |
|
"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 |
|
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 |
|
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. |
|
Great. Everything makes sense now. Thanks again. Cheers. |
|
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? |
|
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. |
|
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. |
|
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. |
|
User support |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-07-21 00:30 |
|
New Issue | |
2015-07-21 08:57 |
|
Tag Attached: Lagrangian | |
2015-07-21 08:57 |
|
Tag Attached: parallel | |
2015-07-21 08:57 |
|
Tag Attached: injection | |
2015-07-21 08:57 |
|
Tag Attached: reconstructPar | |
2015-07-21 09:02 |
|
Note Added: 0005102 | |
2015-07-21 10:10 | will | Note Added: 0005104 | |
2015-07-21 10:25 |
|
Note Added: 0005105 | |
2015-07-21 10:26 |
|
Note Edited: 0005105 | |
2015-07-21 11:15 | will | Note Added: 0005106 | |
2015-07-21 12:23 |
|
Note Added: 0005108 | |
2015-07-21 15:43 | will | Note Added: 0005113 | |
2015-07-21 15:49 |
|
Note Added: 0005114 | |
2015-07-21 16:03 | will | Note Added: 0005115 | |
2015-07-21 16:15 |
|
Note Added: 0005116 | |
2015-07-21 18:01 |
|
Note Edited: 0005116 | |
2015-07-21 21:57 |
|
Note Edited: 0005116 | |
2015-07-22 09:30 | will | Note Added: 0005121 | |
2015-07-22 09:34 |
|
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 |