Number of cells/points in mesh and field don't match
 

Hi there,

after using sHM to create a block mesh, and running pisoFoam, when I am trying to review my data in paraview, I am getting an error message saying:

ERROR: In ..\..\..\..\source\VTK\IO\vtkOpenFOAMReader.cxx, line 6589
vtkOpenFOAMReaderPrivate (0BFF1B08): Number of cells/points in mesh and field don't match: mesh = 23290, field = 8000

I have read the post by colinB but the same solution doesn't seem to apply. Does anybody know how to solve this?

Kind regards,

Kit

Have you run simulation data or are you trying to check your snappyHexMesh? I imagine your blockMesh has 8000 cells, your snappyHexMesh has the 23k. Check to see if you have any datafiles in your directories that don't have uniform values (I'm assuming you haven't actually run a simulation yet).

Hi there,
I have run snappyHexMesh and it appears to be fine in paraview. I then run pisoFoam, which again, appears to be fine, then the problem occurs when I try to put the data into paraview, it comes up with this error message.
I have checked my data files (I assume that means all the files located in the 0 directory; U,p ect) and they all appear to be uniform, apart from R which has a kqRWallFunction entry but no value.
Regards,
Kit

ps, your correct, my blockMesh is 20x20x20=8000

I am guessing you might have solved the problem by now but I also had the same problem.

The reason I had the problem was that the blockMesh was not consistent with the final mesh which snappyHex wrote. I have solved this by using making sure that the polyMesh in the 0 directory which was used for the simulation was the same as that for the folder in which you are opening paraview.

That should solve the problem

Hi there,

Unfortunatly, I haven't got shm to work and i started to build my mesh point by point, block by block. So i'm very interested in your solution, would you be able to explain again what you mean by opening/having the poly mesh folder in the 0 directory?

Kind regards,

Kit

If someone has the same problem, I just found a solution for this... it's a bit "from behind" because you kind of diss Paraview. Before running your simulation, but after running snappyHexMesh just export the mesh using foamMeshToFluent. Then clear your case (pyFoamClearCase.py) and import the mesh again via fluent3DMeshToFoam. Now run your solver! Maybe you'll need to change the patch types in the constant/polyMesh/boundary file, if it doesn't work (in my case I wanted to run a 2D case that I made up with snappyHexMesh and extrudeMesh; the empty front and back patches have been discarded while exporting and importing the mesh and changed into type "patch").

Hi Anna,

How do you export snappyHexMesh into fluent mesh. I am runnig foamMeshToFlent. Unfortunately it gave me just a box!

Thanks in advanced,
Ghazal

This is a solution for people who may be unfamiliar with OpenFOAM.

I encountered this problem when I ran blockMesh then executed a solver only for the simulation to crash/partially run. I edited the mesh and timestep data and re-ran the simulation and got this error when trying to view results in Paraview.

It happened because I still had old timestep data for the old mesh in the case directory, so when paraview read in all timestep data in the case, there were conflicting mesh and fields from the two different sims.

If you're new to OpenFOAM and encounter this error, I suspect this may be why.

I hope this is helpful.

Hi,Kalyan
I had the same problem as you said.
After blockMesh, snappyhexMesh and simpleFoam, I opened paraview to deal with it ,but there was the error
Could you exlain your solution in detail?
Thanks!

I met with the same problem. I run the simulation twice. The first time, the solver was stopped by some other errors. But it saved some results at certain time points. Then, I fixed the errors and run it again. That run was successful. But the error "Number of cells/points in mesh and field don't match" showed in Paraview.
What I did was to delete all of the results, and run the third simulation. Then, errors disappeared. I think it is because the first and the second run had different mesh setup, which led to the don't match error.

I am having the same issue as OP with running interFoam.
Error message:
Number of cells/points in mesh and field don't match: mesh = 23776, field = 8100
I've remade my meshes several times, to no avail. I've also exported to VTK and opened the case in Paraview without using the ubuntu bash.
Could it have something to do with using setFields on the blockmesh, then using SHM, making the number of cells in the mesh different from the setFields?

I had a similar problem. Although it should be easy to fix, I am not sure how to handle it correctly since I am a newbie in OF. Still, definitely it is a step forward.


The root cause is the fact that starting point is at 0 (start time) where the mesh is poor. After running snappyHexMesh, you have a refinement in the castellation step which causes more cells to be generated, thus the number of cells at time 0 is smaller than at time = 1 (where 1 is a step, not a second).

1. Thus, I changed the controlDict file to startFrom latestTime.
2. Of course, there is not value in the time folders for the physical parameters, so you will get an error.
3. I copied the p & U files from 0 to all the time folders (over engineered, since it should work only for the last time step) and ran again.
4. when opening in paraFoam, I ticked the checkBox for skip Zero Time.

That did the trick.
Enjoy

solution
 

found the solution into some Allrun files.



you just need to run: snappyHexMesh -overwrite and it will take care of the problem.

Another possibility behind such message
 

Although quite late and this might seem sort of foolish, but there is one scenario when someone can get this message:

If there are multiple time directories present in the case folder and the mesh in '0' directory is different from the others, then this message pops up due to discrepancy between the meshes in different directories.

Now, this can happen when you are copy-pasting from a old run case and then making some changes in the blockMesh and forget to cleanup (e.g. using 'foamListTimes -rm'), which happened to me :D

Thankyou for this..Now I know what is causing error in my case but still haven't been able to resolve it. I was getting this error while using mirrorMesh in blockMesh. For some reason, using mirrorMesh creates another time folder in main case (although it should not, if anyone can help why it is doing so , that would be great). I deleted that extra time step folder and now I am able to view the results on paraview but it removes the mirrored part of mesh as well :(

Hi Bushra,

Usually OpenFoam utilities avoid to erase data. This is why mirrorMesh creates new time folders when writing the new mesh to preserve the original mesh. Same goes for snappyHexMesh.

To avoid this you have 2 solutions :

• manually delete/rename the original mesh and replace it with the new one (in constant/polyMesh)
• use the overwrite option to overwrite the original mesh with the new one

Cheers,
Yann

Hi!

Thanks alot for your quick reply. The extra time step folder had polymesh genrated after using mirrorMesh. There is already one polyMesh present in constant folder, I have tried over-writing the polymesh in constant folder genrated after using blockMesh with the one created after using mirrorMesh but it gives error when I try to run simulation. Both polymesh folders have different data points with same folder names. I do not know how to merge both of them. Also I don't know if I should change the boundary conditions according to the new mirrored mesh.

Thanks!

The "polyMesh" in the extra timestep directory contains the new mesh created by mirrorMesh.
The "polyMesh" in constant directory is the original mesh created by blockMesh. You can totally delete this one, and move the "polyMesh" directory from the extra timestep to constant.

But the easiest way is to run mirrorMesh with the overwrite option to directly write the mirrored meshed in constant/polyMesh:
Solvers usually read mesh from the constant directory. So if you don't move the new mesh to constant or don't use the overwrite option, you will basically run the solver with the original mesh coming from blockMesh and not with the mirrored one.

Of course you need to have boundary conditions properly defined for the mirrored mesh.

Cheers,
Yann

Thanks alot Yann! I followed your instruction and was able to successfully run simulations using mirrorMesh ..thanks alot!