CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Running, Solving & CFD (
-   -   mapFields problem with 3D (

rcastilla September 11, 2012 13:51

mapFields problem with 3D

when I try to map fields from a case to another with a 3D geometry made with SHM, I found a lot of warnings like these:

--> FOAM Warning :
From function Foam::List<Foam::tetIndices> Foam::polyMeshTetDecomposition::faceTetIndices(con st polyMesh&, label, label)
in file meshes/polyMesh/polyMeshTetDecomposition/polyMeshTetDecomposition.C at line 565
No base point for face 514084, 4(350741 350091 350739 348992), produces a valid tet decomposition.

May be they are not important, but after the mapping the Courant number begins to growth and finally it totally diverges.

The solver is the pimpleFoam. Do you think that this warning with the mapping can be related to the divergence of the solution? Or it is unrelevant and the cause of the divergence is in another place?

I have to add that when I did it with a similar (not exactly the same) case with 2D, I got no warning with the mapping, and the simulation ran fine.

Thank you


mturcios777 September 11, 2012 18:14

Are you mapping consistently or with mapped/cutting patches? And more importantly, what do your mapped fields look like?

rcastilla September 12, 2012 11:43

They are consistent (option -consistent in mapFields)

I don't understand completely what do you mean with what the fields look like... The flow is 3D and it is difficult to show velocity and pressure in a graphic. But, anyway, I have the impression that this warning is more related to the mesh than to physical fields. Why do you think that this is important?

I would like also to know how to mark and show these problematic faces in paraview.



mturcios777 September 12, 2012 11:59

Hi Robert,

The reason I ask about the fields is that when mapping to a snappyHexMesh case, since the boundaries will not be exactly the same you probably won't be able to successfully map all cells, particularly if the target domain is slightly larger than the source domain (look at the user guide entry for mapping fields to see what I mean; basically any cells in your target domain that are outside the source domain geometry don't have a meaningful value given to them).

To fix something like this, have a look at the following thread:

Good luck!

rcastilla September 13, 2012 10:37

Hi, Marco,

finally I got the point. I was mapping to a dynamic mesh which was deformed. I didn't realize that in the deformation process some faces became wrong oriented, and that was the cause of the warning. Anyway, it seems that it is not the cause of the divergence.

Thank you very much for your help!


rcastilla October 17, 2012 02:56

Related to this same issue, I have a doubt.

If I have a dynamic mesh, the points coordinates are changing in time, and they are stored in the file polyMesh/points in each time directory. When I interpolate FROM a time directory in a case, does the mapFields take the points coordinates from the time directory or from the constant/polyMesh directory?

I have the impression that it should take it from the time directory, but I have doubts from the results that I obtain.



All times are GMT -4. The time now is 00:34.