Incorrect Coarsening of Local Mesh

[2022ZM]

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.

[FoamScience]

This somehow went under my radar for some time.

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.

[2022ZM]

Thank you for your previous response. My earlier description may not have been sufficiently clear, which could have caused some misunderstanding. The issue I actually want to describe is as follows.

Figure 1 shows my initial mesh, including the cell level of each mesh. The mesh was generated using blockMesh and snappyHexMesh, which refines local regions. When computing the jet using the official AMR method (dynamicFvMesh + dynamicRefineFvMesh), the cell level and volume fraction at 0.3 ms are shown in Figures 2 and 3, respectively. It can be seen that the AMR technique does not alter the initially refined mesh regions at the starting time. Instead, it uses the initial cell levels as a reference and performs refinement based on the water volume fraction field.

In contrast, using blastAMR at the same time step with dynamicFvMesh + adaptiveFvMesh and refiner polyRefiner (Figure 4), it is observed that the initially refined regions are partially released. This may be because the initial polymesh cell levels are interpreted as being determined by the water volume fraction field, and there is no mechanism to protect the initial mesh cell levels.

Ideally, a mechanism is needed that uses the initial mesh cell levels as a baseline. When detecting regions requiring refinement based on the volume fraction, cells should be refined above their initial level, but cells should not be coarsened below their initial level. For example, for an initial mesh cell (Cell1) with level = 2, if AMR applies 5 levels of refinement and the cell’s volume fraction is 0.5 (within the lower and upper thresholds of 0.01–0.99), then Cell1 should be refined to level = 2 + 3 = 5. Conversely, for an initial mesh cell (Cell2) with level = 2, if AMR applies 5 levels but the cell’s volume fraction is 0.001 or 0.999 (outside the 0.01–0.99 range), the level of Cell2 should remain at 2 without reduction.

[FoamScience]

Hi, yes, this is accurate. #22 introduced the Hex refiner to resolve this situation. Although it's not tested as extensively as the polyRefiner, hexRefiner should always be used if your initial mesh was created with snappyHexMesh and has initial local refinement.

Just for context; the issue here is that refinement history is incompatible between the hex-based algorithms and the one we use here. So my recommendation is:

• snappyHexMesh generated your mesh? -> continue using hexRefiner for the AMR
• Use polyRefiner for all other mesh kinds.

Try it out and let me know if it behaves as expected

[2022ZM]

As you anticipated, when using the hexRefiner method, blastAMR behaves consistently with the official dynamicRefineFvMesh and correctly preserves the initially refined grid region. However, the polyRefiner method exhibits the issue described above, where the initially refined region is improperly released.

Could you please add a protection mechanism for the initial cell-level refinement to the polyRefiner method as well? This is critical for complex meshes. Since most mesh models are complex and are typically generated using snappyHexMesh with localized refinement, the resulting mesh contains both hexahedral and polyhedral cells. During computation, we have to use polyRefiner because hexRefiner fails directly when handling AMR on polyhedral meshes.

This is essential for my work, and I sincerely hope you can implement this feature.

[FoamScience]

snappyHexMesh will always generate pure hex meshes. The 'polyhedral' cells you see there are 'fake hex ones', and are well supported by the AMR engine.

But this is a relatively "easy" fix if we are willing to sacrifice some efficiency. PR #27 works on this issue. Please use the corresponding branch of that PR. If everything works fine, it'll get merged.

Also make sure to read that PR's description, as it introduce new configuration options that must enabled.

[2022ZM]

Thank you for fixing the polyRefiner issue. It now correctly preserves the initial locally refined mesh （time =0）. However, in my current simulations, the refinement history from each time step is being retained. I am not sure if you have observed the same behavior. Since your test only runs for a short duration, this issue might not have been noticeable.

This behavior is different from hexRefiner and dynamicRefineFvMesh (the official method in OpenFOAM v2212). With hexRefiner and dynamicRefineFvMesh, only the initial （time =0） refinement region is kept. They do not retain the refined cells generated at each time step based on the alpha.water field, which otherwise would significantly increase the total refined mesh size.

[2022ZM]

Additionally, I observed another phenomenon: when using the same AMR configuration for both hexRefiner and polyRefiner, with maxRefinement set to 2 for both, the hexRefiner refines to level 2 in the region where alpha.water ranges from 0.001 to 0.999. However, the polyRefiner refinement level appears to be limited to only 1 layer, as shown in the figure.

[FoamScience]

Thanks for the extensive testing! That was a bug and is now fixed! check #27 description for a more detailed description.

[2022ZM]

Thank you very much for your contribution — this is indeed a significant improvement. The initially local refined mesh regions with CellLevel > 0 are now successfully preserved. However, there is still an issue: the mesh refinement caused by the alpha.water boundary field remains within these initially refined regions, resulting in an unintended refinement level increase within the pre-refined zones. As shown in the figure, the spherical initially refined region has been upgraded from level 1 to level 2.

You explained:

“Note that the history cells can be refined but can never be unrefined. This is done this way to prevent degrading the initial geometry as the unrefinement algorithm wouldn't recover the exact initial mesh due to the load-balancer. So the history cells that get refined will stay refined throughout the simulation.”

If a compromise can be made, I would prefer to sacrifice dynamic load balancing in order to use the polyRefiner method while still allowing the initially refined mesh regions to be coarsened back to their original refinement level. I'm not saying dynamic load balancing is bad — it is indeed an excellent feature. However, my priority is to implement adaptive mesh refinement for polyhedral meshes.

For example, when alpha.water = 0 or 1, the spherical refined region should be coarsened back to its original refinement level (level 1), rather than remaining at the maximum refinement level of AMR (level 2) .

[FoamScience]

This is, for now, intended behavior. I have mentioned this in the PR's description. I made the decision to keep things this way for two reasons:

1. Partial unrefinement is currently not supported; at least not in the way we need it to for this issue. Saying "roll back this level 3 region to level 1 cells" is kind of complex and will be a lot of work to code/maintain (especially for complex meshes)
2. Any coarsening operation on these regions risks losing valuable geometry/flow features hence degrading simulation results
   • Think: near-wall refinement to capture geometry features
   • Also think: boundary layers and such
   • Because the unrefinement algorithm is not guaranteed to recover the "original mesh" (due to load-balancing), we have to avoid coarsening these regions. Refining them is Ok though.

My recommendation, for now, plan for your snappyHexMesh refinement to have the same level as your dynamic refinement.

[2022ZM]

ok， anyway， thank you very much.