You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I discovered a bug: when using AMR/LB on a mesh that has been locally refined (refinebox), it will coarsens the local mesh. You can check the results of TScas3. However, OpenFOAM's official dynamicRefineFvMesh mechanism does not have the issue of coarsening local meshes; "It only refines or coarsens the mesh based on the field's range.
The text was updated successfully, but these errors were encountered:
This is not a bug, it's either intended behavior, or a feature request, as I don't provide any special integration with any other refinement tool.
Explanation:
To track refinement/coarsening, blastAMR assigns refinement levels to cells and mesh vertices.
When you run the first updateMesh, the existing cells/points of the mesh are assumed to be at "level 0" unless mesh refinement history files are found (these are polyMesh/cellLevel and polyMesh/pointLevel)
so, if refineBox outputs polyMesh/cellLevel and polyMesh/pointLevel those will get picked up by blastAMR refinement routines. Otherwise, the starting mesh will be assigned a cell level of 0 everywhere.
so just remove cellLevel/pointLevel files before running the first updateMesh to get the effect you want.
It would be a feature request to "protect cell sets/zones" from refinement/coarsening, which would be nice to have but has low priority since it can be achieved easily with a coded refinement.
I discovered a bug: when using AMR/LB on a mesh that has been locally refined (refinebox), it will coarsens the local mesh. You can check the results of TScas3. However, OpenFOAM's official dynamicRefineFvMesh mechanism does not have the issue of coarsening local meshes; "It only refines or coarsens the mesh based on the field's range.
The text was updated successfully, but these errors were encountered: