no base point for face xxx

eugene.katsevman · June 24, 2011, 12:57

Hello!
I'm pretty new to OpenFOAM. Now I'm trying to use dsmc solver. Now I'm getting a bunch of dsmcInitialize warnings like that:

--> FOAM Warning :
From function Foam::List<Foam::FixedList<Foam::label, 4> >Foam::Cloud<ParticleType>::faceTetIndices(label fI, label cI) const
in file meshes/polyMesh/polyMeshTetDecomposition/polyMeshTetDecomposition.C at line 561
No base point for face 25085, 3(3298 2596 2567), produces a valid tet decomposition.

I've tried to google it, but have no success. Where should I look and what's wrong exactly?

Thanks in advance.

johnsmith332 · February 27, 2012, 00:54

I've been having the same problem trying to run dsmc with snappyHexMesh. Has anyone figured this out?

Sylvain · February 27, 2012, 10:09

Hi everybody

Same here with the uncoupledKinematicparcelFoam. I found out that it was very sensitive to the mesh quality at the surface.
I succeed in avoiding the problem with basic meshes. But if your mesh is a bit complex it crashes every time a particle enter a cell whose shape is not so nice. So I don't know what to do.
The problem is that it is crashing the whole calculation, ,not only the individual particle.

Sylvain

Sylvain · February 27, 2012, 11:47

I tried to comment the part of the code that makes the code crash in the src/lagrangian/basic.particleI.H

As a result, the calculation doesn't crash any longer, but the code seemed to be caught in infinite loop and the calculation is stuck to one time step.

Means that this piece of code as a purpose after all!!!

Anyone as a solution?

Sylvain

Sylvain · February 28, 2012, 02:35

Hello John,

I'm trying to figure out why some of my meshes are working well, and why some others not.

I have tried 3 meshes generated with harpoon:

-1 with BL => it crashes, checkMesh told me that there was few cell with skewness but not a big deal
-1 whithout BL but with zero-thickness surfaces => it crashes => checkMesh told me about non-manifold points
-1 wihtout BL and whithout zero-thicknesse => it works => chekmesh reports few celles with skewness

I never had any problem with meshes generated with snappy before. Now I thinking about the zero-thicknesses surfaces which might be a problem (the particles don't know if it hits the above or below of the face?)

Do your mesh contains such surfaces, baffles, or weird BLs

johnsmith332 · February 28, 2012, 15:59

The geometry I used was pretty simple: a 3 inch bolt with no thread, so just an extruded hexagon and a cylinder. I've tried changing the mergeTolerance in snappyHexMesh, but nothing happened. I have no idea which tolerance the error is referring to. The only thing I really wrote myself was the snappyHexMeshdict, but then your having the same problem without snappy..

Sylvain · February 29, 2012, 02:35

hello John,

Thank you for your message. What did checkMesh say when you ran it on your mesh?

I'm pretty convinced that it has something to do with the mesh.
Yesterday I tried to get rid of all the non manifold points on may baffles using mergeOrSplitBaffle utility. But it only delayed the problem to another face.

So I don't know why it is working fine sometimes and not I other cases.

i'm going on with my investigations.

Sylvain · February 29, 2012, 11:12

Ok, last update!
i ran a calculation on a mesh made by a colleague with snappy. the mesh is far more than ugly, but well, it's working without any problem. So I don't understand.

johnsmith332 · March 2, 2012, 13:40

When I run checkMesh is gives me a bunch of ok's with no errors or warnings. However, in the final mesh, checkMesh lists the number of cells of each type, and there are a bunch of each type except tetrahedral, of which there is only 1 which seems strange. Also, in the source code where the error is, it mentions variables like tetFacel_ and tetBasePtI which I assume refers to tetrahedral cells, so perhaps this 1 cell is causing problems.

Sylvain · March 7, 2012, 12:00

Hello John,

i got the problem again today. something weird: the face which makes the run crash belongs to perfect hexa cell located far away from the particles.

I'm puzzled. For all my experiments, the problem arises with meshes from harpoon. Would be my conclusion except from the fact you have problem with snappy also... still I'm not yet confident with meshes from harpoon to OF

Anyone else had this issue before?

ybapat · June 12, 2012, 00:22

Helllo,

I also got same error mentioned in first post.

OpenFOAM release notes for 2.0.0 mention that polymesh used must pass test
checkMesh -allGeometry by giving message "Face tets OK" to run the particle case.

You can try running this check on your mesh and check if it fails.

Regards,
-Yogesh

Sylvain · June 12, 2012, 01:57

Thanks Yogesh for your message!

I have checked this morning on my previous case mentioned above. The "Face tets OK" indeed failed on the mesh which was not working. The test is good on the mesh which works.

Conclusion: adding this -allGeometry option allows to anticipate if your Mesh going to crash on Lagrangian simulations.

Thank you very much again Yogesh!

June 24, 2011, 12:57	no base point for face xxx	#1
eugene.katsevman New Member Eugene Katsevman Join Date: Jun 2011 Posts: 1 Rep Power: 0	Hello! I'm pretty new to OpenFOAM. Now I'm trying to use dsmc solver. Now I'm getting a bunch of dsmcInitialize warnings like that: --> FOAM Warning : From function Foam::List<Foam::FixedList<Foam::label, 4> >Foam::Cloud<ParticleType>::faceTetIndices(label fI, label cI) const in file meshes/polyMesh/polyMeshTetDecomposition/polyMeshTetDecomposition.C at line 561 No base point for face 25085, 3(3298 2596 2567), produces a valid tet decomposition. I've tried to google it, but have no success. Where should I look and what's wrong exactly? Thanks in advance.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
matching variable data with grid point data	anfho	OpenFOAM Programming & Development	0	May 6, 2011 15:28
CFX Post: Problems with moving point cloud for changing time steps	spatialtime	CFX	0	December 7, 2009 04:56
BlockMeshmergePatchPairs	hjasak	OpenFOAM Native Meshers: blockMesh	11	August 15, 2008 07:36
Gmsh and samplesurface	touf	Open Source Meshers: Gmsh, Netgen, CGNS, ...	2	December 10, 2007 02:27
CFX4.3 -build analysis form	Chie Min	CFX	5	July 12, 2001 23:19

February 27, 2012, 00:54		#2
johnsmith332 New Member John Smith Join Date: Feb 2012 Posts: 4 Rep Power: 3	I've been having the same problem trying to run dsmc with snappyHexMesh. Has anyone figured this out?

February 27, 2012, 10:09		#3
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	Hi everybody Same here with the uncoupledKinematicparcelFoam. I found out that it was very sensitive to the mesh quality at the surface. I succeed in avoiding the problem with basic meshes. But if your mesh is a bit complex it crashes every time a particle enter a cell whose shape is not so nice. So I don't know what to do. The problem is that it is crashing the whole calculation, ,not only the individual particle. Sylvain

February 27, 2012, 11:47		#4
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	I tried to comment the part of the code that makes the code crash in the src/lagrangian/basic.particleI.H As a result, the calculation doesn't crash any longer, but the code seemed to be caught in infinite loop and the calculation is stuck to one time step. Means that this piece of code as a purpose after all!!! Anyone as a solution? Sylvain

February 28, 2012, 02:35		#5
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	Hello John, I'm trying to figure out why some of my meshes are working well, and why some others not. I have tried 3 meshes generated with harpoon: -1 with BL => it crashes, checkMesh told me that there was few cell with skewness but not a big deal -1 whithout BL but with zero-thickness surfaces => it crashes => checkMesh told me about non-manifold points -1 wihtout BL and whithout zero-thicknesse => it works => chekmesh reports few celles with skewness I never had any problem with meshes generated with snappy before. Now I thinking about the zero-thicknesses surfaces which might be a problem (the particles don't know if it hits the above or below of the face?) Do your mesh contains such surfaces, baffles, or weird BLs

February 28, 2012, 15:59		#6
johnsmith332 New Member John Smith Join Date: Feb 2012 Posts: 4 Rep Power: 3	The geometry I used was pretty simple: a 3 inch bolt with no thread, so just an extruded hexagon and a cylinder. I've tried changing the mergeTolerance in snappyHexMesh, but nothing happened. I have no idea which tolerance the error is referring to. The only thing I really wrote myself was the snappyHexMeshdict, but then your having the same problem without snappy..

February 29, 2012, 02:35		#7
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	hello John, Thank you for your message. What did checkMesh say when you ran it on your mesh? I'm pretty convinced that it has something to do with the mesh. Yesterday I tried to get rid of all the non manifold points on may baffles using mergeOrSplitBaffle utility. But it only delayed the problem to another face. So I don't know why it is working fine sometimes and not I other cases. i'm going on with my investigations.

February 29, 2012, 11:12		#8
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	Ok, last update! i ran a calculation on a mesh made by a colleague with snappy. the mesh is far more than ugly, but well, it's working without any problem. So I don't understand.

March 2, 2012, 13:40		#9
johnsmith332 New Member John Smith Join Date: Feb 2012 Posts: 4 Rep Power: 3	When I run checkMesh is gives me a bunch of ok's with no errors or warnings. However, in the final mesh, checkMesh lists the number of cells of each type, and there are a bunch of each type except tetrahedral, of which there is only 1 which seems strange. Also, in the source code where the error is, it mentions variables like tetFacel_ and tetBasePtI which I assume refers to tetrahedral cells, so perhaps this 1 cell is causing problems.

March 7, 2012, 12:00		#10
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	Hello John, i got the problem again today. something weird: the face which makes the run crash belongs to perfect hexa cell located far away from the particles. I'm puzzled. For all my experiments, the problem arises with meshes from harpoon. Would be my conclusion except from the fact you have problem with snappy also... still I'm not yet confident with meshes from harpoon to OF Anyone else had this issue before?

June 12, 2012, 00:22		#11
ybapat New Member Yogesh Bapat Join Date: Oct 2010 Posts: 12 Rep Power: 4	Helllo, I also got same error mentioned in first post. OpenFOAM release notes for 2.0.0 mention that polymesh used must pass test checkMesh -allGeometry by giving message "Face tets OK" to run the particle case. You can try running this check on your mesh and check if it fails. Regards, -Yogesh

June 12, 2012, 01:57		#12
Sylvain Member Sylvain Aguinaga Join Date: Feb 2010 Posts: 32 Rep Power: 5	Thanks Yogesh for your message! I have checked this morning on my previous case mentioned above. The "Face tets OK" indeed failed on the mesh which was not working. The test is good on the mesh which works. Conclusion: adding this -allGeometry option allows to anticipate if your Mesh going to crash on Lagrangian simulations. Thank you very much again Yogesh!