OversetMesh zone voxels and bb weirdness

lhcamilo · September 17, 2019, 10:07

Dear all.

I have been playing with overset grids in openfoam and it has been a rather... frustrating experience. I have been able to make it sorta work, but at some point it complains that (paraphrasing) at zone0, blocks go from hole to calculated but it has no source,

As far as I can understand this means that the host grid is not able to follow the moving grid by updating the hole cells in itself.

In order to trouble shoot it I have noticed some weirdness in the log file.

Namely, when I run "moveDynamicMesh" there is a section that refers to the zones in the case. here is an example

Code:

zone:0 nCells:682052  voxels:(100 100 1) bb:(0 0 0) (0.01 0.01 0.01)
zone:1 nCells:41344  voxels:(100 100 1) bb:(0 0 0) (0.01 0.01 0.01)

The weird thing is that the voxels and the bb (boundingbox) have these weird values, while the number of cells have the correct cell count.

I have been playing with the pre-processing script and here is what it looks like at the moment.

Code:

rm -rf 0
#cartesianMesh
rm  -rf constant/polyMesh
cp -r constant/polyMeshOverset constant/polyMesh
mergeMeshes . ../closedPiston -overwrite
#checkMesh | tee checkMesh00.log


rm -rf 0
#checkMesh | tee checkMesh01.log
topoSet | tee topoSet.log
cp -r zero 0
setFields | tee setFields.log
renumberMesh -overwrite

Of course there is a bunch of details missing, but do what I want to know is if this log weirdness is a clue to my problem or if really does not matter?

Thanks in advance. And sorry for the convoluted post, I have been hammering at this for a bit and it has been rather frustrating.

lhcamilo · September 18, 2019, 13:33

Well, it seems that my problem was sheer stupidity.

For some reason the boudingbox and voxel division was specified in the fvSchemes file...

le sigh

September 17, 2019, 10:07	OversetMesh zone voxels and bb weirdness	#1
lhcamilo Member Leonardo Honfi Camilo Join Date: Mar 2009 Location: Delft, Zuid Holland, The Netherlands Posts: 60 Rep Power: 17	Dear all. I have been playing with overset grids in openfoam and it has been a rather... frustrating experience. I have been able to make it sorta work, but at some point it complains that (paraphrasing) at zone0, blocks go from hole to calculated but it has no source, As far as I can understand this means that the host grid is not able to follow the moving grid by updating the hole cells in itself. In order to trouble shoot it I have noticed some weirdness in the log file. Namely, when I run "moveDynamicMesh" there is a section that refers to the zones in the case. here is an example Code: zone:0 nCells:682052 voxels:(100 100 1) bb:(0 0 0) (0.01 0.01 0.01) zone:1 nCells:41344 voxels:(100 100 1) bb:(0 0 0) (0.01 0.01 0.01) The weird thing is that the voxels and the bb (boundingbox) have these weird values, while the number of cells have the correct cell count. I have been playing with the pre-processing script and here is what it looks like at the moment. Code: rm -rf 0 #cartesianMesh rm -rf constant/polyMesh cp -r constant/polyMeshOverset constant/polyMesh mergeMeshes . ../closedPiston -overwrite #checkMesh \| tee checkMesh00.log rm -rf 0 #checkMesh \| tee checkMesh01.log topoSet \| tee topoSet.log cp -r zero 0 setFields \| tee setFields.log renumberMesh -overwrite Of course there is a bunch of details missing, but do what I want to know is if this log weirdness is a clue to my problem or if really does not matter? Thanks in advance. And sorry for the convoluted post, I have been hammering at this for a bit and it has been rather frustrating.

September 18, 2019, 13:33		#2
lhcamilo Member Leonardo Honfi Camilo Join Date: Mar 2009 Location: Delft, Zuid Holland, The Netherlands Posts: 60 Rep Power: 17	Well, it seems that my problem was sheer stupidity. For some reason the boudingbox and voxel division was specified in the fvSchemes file... le sigh Last edited by lhcamilo; September 19, 2019 at 08:17.