|
[Sponsors] |
[snappyHexMesh] Number of cells/points in mesh and field don't match |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
January 5, 2012, 10:07 |
Number of cells/points in mesh and field don't match
|
#1 |
New Member
Join Date: Nov 2011
Posts: 22
Rep Power: 15 |
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 |
|
January 5, 2012, 15:20 |
|
#2 |
Senior Member
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 740
Rep Power: 28 |
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).
|
|
January 5, 2012, 16:05 |
|
#3 |
New Member
Join Date: Nov 2011
Posts: 22
Rep Power: 15 |
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 |
|
January 5, 2012, 16:05 |
|
#4 |
New Member
Join Date: Nov 2011
Posts: 22
Rep Power: 15 |
ps, your correct, my blockMesh is 20x20x20=8000
|
|
January 25, 2012, 17:32 |
|
#5 |
Member
|
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 |
|
January 26, 2012, 04:43 |
|
#6 |
New Member
Join Date: Nov 2011
Posts: 22
Rep Power: 15 |
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 |
|
May 19, 2015, 10:30 |
|
#7 |
New Member
Anna
Join Date: Apr 2015
Location: Stuttgart, Germany
Posts: 3
Rep Power: 11 |
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").
|
|
March 2, 2017, 05:41 |
|
#8 |
New Member
Join Date: Jan 2017
Posts: 13
Rep Power: 9 |
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 |
|
March 23, 2017, 12:16 |
|
#9 |
New Member
Joanne Campbell
Join Date: Mar 2017
Posts: 4
Rep Power: 9 |
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. |
|
March 15, 2019, 05:41 |
|
#10 | |
New Member
Excercise
Join Date: Feb 2019
Posts: 11
Rep Power: 7 |
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! Quote:
|
||
May 21, 2019, 21:38 |
|
#11 |
New Member
Wei
Join Date: May 2019
Posts: 1
Rep Power: 0 |
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. |
|
August 2, 2019, 04:26 |
|
#12 |
New Member
Mads Ivarson
Join Date: Jul 2019
Posts: 17
Rep Power: 7 |
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? |
|
January 25, 2020, 06:31 |
|
#13 | |
New Member
Catalin
Join Date: Jan 2020
Posts: 4
Rep Power: 6 |
Quote:
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).
That did the trick. Enjoy |
||
January 25, 2020, 16:17 |
solution
|
#14 |
New Member
Catalin
Join Date: Jan 2020
Posts: 4
Rep Power: 6 |
found the solution into some Allrun files.
you just need to run: snappyHexMesh -overwrite and it will take care of the problem. |
|
February 4, 2021, 13:58 |
Another possibility behind such message
|
#15 |
Member
Sourav Mandal
Join Date: Jul 2019
Posts: 55
Rep Power: 7 |
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 |
|
March 17, 2021, 05:41 |
|
#16 | |
Member
Bushra Rasheed
Join Date: Dec 2020
Posts: 97
Rep Power: 5 |
Quote:
|
||
March 17, 2021, 06:15 |
|
#17 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,207
Rep Power: 28 |
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 :
Yann |
|
March 17, 2021, 06:25 |
|
#18 | |
Member
Bushra Rasheed
Join Date: Dec 2020
Posts: 97
Rep Power: 5 |
Quote:
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! |
||
March 17, 2021, 07:06 |
|
#19 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,207
Rep Power: 28 |
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: Code:
mirrorMesh -overwrite Of course you need to have boundary conditions properly defined for the mirrored mesh. Cheers, Yann |
|
March 18, 2021, 07:27 |
|
#20 | |
Member
Bushra Rasheed
Join Date: Dec 2020
Posts: 97
Rep Power: 5 |
Quote:
|
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Foam::error::PrintStack | almir | OpenFOAM Running, Solving & CFD | 92 | May 21, 2024 08:56 |
[snappyHexMesh] Error snappyhexmesh - Multiple outside loops | avinashjagdale | OpenFOAM Meshing & Mesh Conversion | 53 | March 8, 2019 10:42 |
[mesh manipulation] Importing Multiple Meshes | thomasnwalshiii | OpenFOAM Meshing & Mesh Conversion | 18 | December 19, 2015 19:57 |
SigFpe when running ANY application in parallel | Pj. | OpenFOAM Running, Solving & CFD | 3 | April 23, 2015 15:53 |
Moving mesh | Niklas Wikstrom (Wikstrom) | OpenFOAM Running, Solving & CFD | 122 | June 15, 2014 07:20 |