View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001461 | OpenFOAM | Bug | public | 2014-12-12 16:16 | 2015-01-01 13:35 |
| Reporter | Assigned To | henry | |||
| Priority | normal | Severity | crash | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu | OS Version | 14.04 LTS |
| Summary | 0001461: reconstructPar lagrangian particles | ||||
| Description | After completing a simulation in parallel with Lagrangian particles (injection randomized from a patch), I got the following issue when using reconstructPar: Reconstructing point fields No point fields Reconstructing lagrangian fields for cloud kinematicCloud --> FOAM FATAL ERROR: cell, tetFace and tetPt search failure at position (-0.076367044973 -0.019984101137 0.03252561485) for requested cell 30085 From function void Foam::particle::initCellFacePt() in file lnInclude/particleI.H at line 758. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) in "/usr/local/non-commercial/OpenFOAM/2.3.0/OpenFOAM-2.3.0/platforms/linux64IccDPOpt/lib/libOpenFOAM.so" #1 Foam::error::abort() in "/usr/local/non-commercial/OpenFOAM/2.3.0/OpenFOAM-2.3.0/platforms/linux64IccDPOpt/lib/libOpenFOAM.so" #2 Foam::particle::initCellFacePt() in "/usr/local/non-commercial/OpenFOAM/2.3.0/OpenFOAM-2.3.0/platforms/linux64IccDPOpt/lib/liblagrangian.so" #3 Foam::Cloud<Foam::passiveParticle>::initCloud(bool) in "/usr/local/non-commercial/OpenFOAM/2.3.0/OpenFOAM-2.3.0/platforms/linux64IccDPOpt/lib/libreconstruct.so" #4 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&) in "/usr/local/non-commercial/OpenFOAM/2.3.0/OpenFOAM-2.3.0/platforms/linux64IccDPOpt/lib/libreconstruct.so" #5 in "/usr/local/non-commercial/OpenFOAM/2.3.0/OpenFOAM-2.3.0/platforms/linux64IccDPOpt/bin/reconstructPar" #6 __libc_start_main in "/lib64/libc.so.6" #7 at /usr/src/packages/BUILD/glibc-2.11.3/csu/../sysdeps/x86_64/elf/start.S:116 Aborted I looked into the code, and from what I understand, this is the FatalError in particleI.H line 758. This happens when the assigned particle cell is not correct one. So an easy fix for this could be (in particleI.H): if (!mesh_.pointInCellBB(position_, oldCellI, 0.1)) { label correctedCellI = mesh_.findCell(position_); mesh_.findCellFacePt ( position_, correctedCellI, tetFaceI_, tetPtI_ ); return; } | ||||
| Steps To Reproduce | Run a Lagrangian (icoUncoupledKinematicParcelFoam, for instance) parallel case (with a large number of parcels injected close to a wall, and using "stick" as wall Interaction Model), for a very fine mesh (first cell y+ = 1). Then run "reconstructPar". The bug might occur. No need to use foamToVTK. | ||||
| Additional Information | This bug seems similar to 0001341, see: http://www.openfoam.org/mantisbt/view.php?id=1341 | ||||
| Tags | No tags attached. | ||||
|
|
A couple of requests: 1. Can you please try the latest OpenFOAM 2.3.1 to see if this is already fixed? Because you indicated that the product version was "2.3.x", but the stack trace clearly indicates that you're using 2.3.0. 2. If the error still occurs with 2.3.1, could you perhaps prepare and upload an example case based on a tutorial from OpenFOAM that reproduces this problem? Because from your description, it's a matter of luck to be able to reproduce this problem, which makes it improbable to solve, without spending some considerable time to just find said example case. |
|
|
Note: This also seems related to http://www.openfoam.org/mantisbt/view.php?id=1097 |
|
|
Are you writing the data ascii or binary? The issue may relate to loss of precision when writing in ascii which causes the particle to apparently move between cells. Nevertheless, an automatic correction procedure similar to the one you propose, would be a good idea and we will consider this further. |
|
|
Well, it's true that I generally write the data in ascii rather than in binary. I will try doing it in binary. By the way, all openFoam tools that link the same file (particleI.H) will have the same problem. This includes decomposing a case with misplaced particles with decomposePar. |
|
|
Your proposed fix is not sufficient: if the particle is slightly outside the domain mesh_.findCell(position_) won't find it. In fact the necessary correction logic is already present in particleI.H but relies on the mesh_.pointInCellBB(position_, oldCellI, 0.1) finding the particle in the extended cell bounding box. If this fails it indicates that cell is VERY thin and the particle is outside the cell by more than 10% of the thickness of the cell which is a very significant error. This indicates that for your mesh the loss of accuracy you are incurring in your choice of write precision and ascii output is unacceptable and you really should be writing binary or increase the write precision but this will make the file sizes larger than with binary. I will add a better diagnostic message to provide this kind of recommendation but if for some reason users really need particle positions to recover from this kind of extreme error I could change the way in which the cell bounding box to be more isotropic. I am testing this at the moment. |
|
|
Resolved by commits: commit 3891c6ada0248435ad62a30f30e7d0be9df8abd5 commit 7200eb272ab8dd0d754552edfa0753d4c5a15983 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-12-12 16:16 |
|
New Issue | |
| 2014-12-13 19:12 | wyldckat | Note Added: 0003311 | |
| 2014-12-29 18:23 | wyldckat | Note Added: 0003410 | |
| 2014-12-30 10:35 | henry | Note Added: 0003414 | |
| 2014-12-30 11:12 |
|
Note Added: 0003415 | |
| 2015-01-01 12:44 | henry | Note Added: 0003430 | |
| 2015-01-01 13:35 | henry | Note Added: 0003431 | |
| 2015-01-01 13:35 | henry | Status | new => resolved |
| 2015-01-01 13:35 | henry | Resolution | open => fixed |
| 2015-01-01 13:35 | henry | Assigned To | => henry |
