Access mesh cell refinement levels from solver.

OlegSutyrin · January 1, 2017, 11:41

Hi!
I'm developing [slightly more] advanced AMR method for rhoCentralDyMFoam using density gradient field. I have succeeded mostly, and will post it in this forum after some additional adjustments and tests. The only major difficulty I have is that I need to access current cell refinement level for each cell. For now I've implemented a workaround - calculation from initial and current cell sizes, but it is sloppy and costly. Direct access to cell levels would be much more effective.

As far as I know, these data are obtainable from 'hexRef8' class, which is used as 'meshCutter_' in 'dynamicRefineFvMesh' class. The problem is, when I try to call mesh.meshCutter() function, compiler tells: "error: 'class Foam::dynamicFvMesh' has no member named meshCutter".

Why mesh is of 'dynamicFvMesh' type but not of 'dynamicRefineFvMesh' type?
How to properly access meshCutter from the solver?
If it is not accessible, how should I modify the code of dynamicFvMesh or hexRef8 classes to make it accessible?

fra76 · January 2, 2017, 07:02

Dear Oleg,
I might be wrong, but the mesh refinement level is only used by octree-based meshes, like snappyHexMesh and automatic refinement algorithms you can have in solvers. For example, you can start snappyHexMesh from a mesh having only hexahedra, which are the only elements it can refine.
A general purpose solver does not have access natively to this information because it might simply not exist. Imagine a fully-tet mesh where the tetrahedra size varies smoothly from far field to the surface.

If you use snappyHexMesh, you can use the cellLevel field it writes during the meshing process. If the field is not found, then you can switch to your expensive algorithm.

Hope this helps,
Francesco

OlegSutyrin · January 2, 2017, 07:17

Dear fra76, thanks for the reply!
Physical problems that I simulate don't have any complex surfaces, boundary layers etc. So I don't use snappyHexMesh and instead use the simplest possible mesh - parallelepipedal - which is also the most suitable for AMR.

I'n sure that information on cell level refinement levels exists somewhere, because OpenFOAM's AMR is reversible, and levels somehow can be dumped into file along with refinement history. At least, it is certainly exist (or created each time) when we call 'mesh.update()', where AMR actually takes place.
I'm hoping to find a way to access this info from solver or make it accessible by some core engine code editing, and asking here for some guidance.

January 1, 2017, 11:41	Access mesh cell refinement levels from solver.	#1
OlegSutyrin Member Oleg Sutyrin Join Date: Feb 2016 Location: Russia Posts: 41 Rep Power: 10	Hi! I'm developing [slightly more] advanced AMR method for rhoCentralDyMFoam using density gradient field. I have succeeded mostly, and will post it in this forum after some additional adjustments and tests. The only major difficulty I have is that I need to access current cell refinement level for each cell. For now I've implemented a workaround - calculation from initial and current cell sizes, but it is sloppy and costly. Direct access to cell levels would be much more effective. As far as I know, these data are obtainable from 'hexRef8' class, which is used as 'meshCutter_' in 'dynamicRefineFvMesh' class. The problem is, when I try to call mesh.meshCutter() function, compiler tells: "error: 'class Foam::dynamicFvMesh' has no member named meshCutter". Why mesh is of 'dynamicFvMesh' type but not of 'dynamicRefineFvMesh' type? How to properly access meshCutter from the solver? If it is not accessible, how should I modify the code of dynamicFvMesh or hexRef8 classes to make it accessible?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[snappyHexMesh] Error snappyhexmesh - Multiple outside loops	avinashjagdale	OpenFOAM Meshing & Mesh Conversion	53	March 8, 2019 09:42
Star cd es-ice solver error	ernarasimman	STAR-CD	2	September 12, 2014 00:01
[snappyHexMesh] snappyHexMesh refinement regions ignored	guitarbren	OpenFOAM Meshing & Mesh Conversion	2	April 9, 2013 03:59
killed "snappyHexMesh"	parkh32	OpenFOAM Pre-Processing	2	April 8, 2012 17:12
[snappyHexMesh] snappyHexMesh won't work - zeros everywhere!	sc298	OpenFOAM Meshing & Mesh Conversion	2	March 27, 2011 21:11

January 2, 2017, 07:02		#2
fra76 Senior Member Francesco Del Citto Join Date: Mar 2009 Location: Zürich Area, Switzerland Posts: 237 Rep Power: 18	Dear Oleg, I might be wrong, but the mesh refinement level is only used by octree-based meshes, like snappyHexMesh and automatic refinement algorithms you can have in solvers. For example, you can start snappyHexMesh from a mesh having only hexahedra, which are the only elements it can refine. A general purpose solver does not have access natively to this information because it might simply not exist. Imagine a fully-tet mesh where the tetrahedra size varies smoothly from far field to the surface. If you use snappyHexMesh, you can use the cellLevel field it writes during the meshing process. If the field is not found, then you can switch to your expensive algorithm. Hope this helps, Francesco

January 2, 2017, 07:17		#3
OlegSutyrin Member Oleg Sutyrin Join Date: Feb 2016 Location: Russia Posts: 41 Rep Power: 10	Dear fra76, thanks for the reply! Physical problems that I simulate don't have any complex surfaces, boundary layers etc. So I don't use snappyHexMesh and instead use the simplest possible mesh - parallelepipedal - which is also the most suitable for AMR. I'n sure that information on cell level refinement levels exists somewhere, because OpenFOAM's AMR is reversible, and levels somehow can be dumped into file along with refinement history. At least, it is certainly exist (or created each time) when we call 'mesh.update()', where AMR actually takes place. I'm hoping to find a way to access this info from solver or make it accessible by some core engine code editing, and asking here for some guidance.