View Issue Details

IDProjectCategoryView StatusLast Update
0001341OpenFOAMBugpublic2015-01-01 13:37
Reporteransubru Assigned Towill  
PriorityimmediateSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version12.04 LTS
Summary0001341: cell, tetFace and tetPt search failure while reconstructing fields for post-processing (icoUncoupledKinematicParcelDyMFoam)
DescriptionI am using the icoUncoupledKinematicParcelDyMFoam to run a simple case of a dynamic domain (transverse movement). The solver seems to be solving the necessary 'kinematic cloud' however, when i try to reconstruct the results using foamToVTK (for post-processing) I get the following error -

 --> FOAM FATAL ERROR:
cell, tetFace and tetPt search failure at position (0.0051578869 -0.002436563 0.063898536)
for requested cell 543

    From function void Foam::particle::initCellFacePt()
    in file /home/ask/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/basic/lnInclude/particleI.H at line 758.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OSspecific/POSIX/printStack.C:221
#1 Foam::error::abort() at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/error.C:249
#2 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/errorManip.H:85
#3 Foam::particle::initCellFacePt() at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/basic/lnInclude/particleI.H:775
#4 Foam::Cloud<Foam::passiveParticle>::initCloud(bool) at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/basic/lnInclude/CloudIO.C:141
#5 Foam::Cloud<Foam::passiveParticle>::Cloud(Foam::polyMesh const&, Foam::word const&, bool) at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/basic/lnInclude/CloudIO.C:188
#6
 at ~/OpenFOAM/OpenFOAM-2.3.0/applications/utilities/postProcessing/dataConversion/foamToVTK/lagrangianWriter.C:64
#7
 at ~/OpenFOAM/OpenFOAM-2.3.0/applications/utilities/postProcessing/dataConversion/foamToVTK/foamToVTK.C:1150
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9
 in "/home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/bin/foamToVTK"
Aborted (core dumped)
Steps To ReproduceExecute the case (run simulation with icoUncoupledKinematicParcelDyMFoam)

Obtain some I/O data (time data sampling)

Run foamToVTK for post processing

Error immediately manifests
Additional InformationI am attaching the tar-ball of my case-setup so that the necessary bug fixes can be applied. I believe that this is a problem for any icoUncoupledKinematicParcelDyMFoam post- processing step.
TagsNo tags attached.

Activities

ansubru

2014-07-09 09:04

reporter  

will

2014-07-25 14:10

manager   ~0003175

The location reported by the error message is outside the domain, above the inlet patch. Patch injection chooses locations randomly, which can result in the particles overlapping. Overlap results in huge forces and velocities, which might break the tracking. It's therefore generally not a good idea to do patch injection of pair-colliding particles.

I can't reproduce this error, but seeing as how it might be a function of random number generation, this isn't surprising.

ansubru

2014-07-28 09:44

reporter   ~0003180

Hi Will!!

Thank you for monitoring this bug. However, I still don't understand the fix. I changed my particle injection to 'manual' using the kinematiccloudpositions file (no randomness in the particle positions) and I still continue to get the same error.

What parameters did you use when setting up the 'tar-ball' of the case uploaded with this issue? I wanted to know how how you have overcome this error.

Is there something wrong with my set-up now (could you share your tar-ball case set up)?? During run time i get this warning msg as well -

--> FOAM Warning :
    From function void Foam::InteractionLists<ParticleType>::sendReferredData(const List<DynamicList<ParticleType*> >& cellOccupancy,PstreamBuffers& pBufs)
    in file /home/ask/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/basic/lnInclude/InteractionLists.C at line 1175
    Mesh changing, rebuilding InteractionLists form scratch.
Building InteractionLists with interaction distance 0.0025
    Building referred interaction lists
    Building direct interaction lists

Is this normal?? Or is it here that the source of this error lies??

BR

ansubru

will

2014-07-28 13:10

manager  

will

2014-07-28 13:10

manager  

overlap_velocity.png (64,286 bytes)   
overlap_velocity.png (64,286 bytes)   

will

2014-07-28 13:15

manager   ~0003181

Apologies, I wasn't running the dynamic mesh part. I can, in fact, reproduce the error.

That warning message is to be expected for a dynamic mesh case.

I have looked some more at your case, and I still think the problem is overlap at the point of injection. The overlap is generating large velocities at the start. The youngs modulus is also very low, so the calculated wall force is insufficient to keep the particles in the domain. An actual particle, with that youngs modulus, and at that speed, would splat, not rebound.

I've attached my case, which uses a manual injection without any overlap. The difference between the particle velocities in the two cases is shown in the uploaded image. The particles don't escape in my setup.

henry

2015-01-01 13:37

manager   ~0003432

Resolved by commits:
    commit 3891c6ada0248435ad62a30f30e7d0be9df8abd5
    commit 7200eb272ab8dd0d754552edfa0753d4c5a15983

See also the discussion in thread
    http://www.openfoam.org/mantisbt/view.php?id=1461

Issue History

Date Modified Username Field Change
2014-07-09 09:04 ansubru New Issue
2014-07-09 09:04 ansubru File Added: gravity_table_dynamic.tar.gz
2014-07-25 14:10 will Note Added: 0003175
2014-07-28 09:44 ansubru Note Added: 0003180
2014-07-28 13:10 will File Added: gravity_table_dynamic_new.tar.gz
2014-07-28 13:10 will File Added: overlap_velocity.png
2014-07-28 13:15 will Note Added: 0003181
2014-07-28 13:16 will Status new => closed
2014-07-28 13:16 will Assigned To => will
2014-07-28 13:16 will Resolution open => fixed
2015-01-01 13:37 henry Note Added: 0003432
2015-01-01 13:37 henry Status closed => resolved