Open andrewwinters5000 opened 2 years ago
As a followup to the discussion today I threw together a quick loop that computes the shortest element side length of a mesh given only the mesh
and using its tree_node_coordinates
. This could be done during the mesh construction to compute an element-wise value of the baseline h
or maybe done on the fly (I have not tested how expensive this would be)
nnodes = length(mesh.nodes)
nelements = last(size(mesh.tree_node_coordinates))
for k in 1:nelements
# pull the four corners numbered as right-handed
P0 = mesh.tree_node_coordinates[:, 1 , 1 , k]
P1 = mesh.tree_node_coordinates[:, nnodes, 1 , k]
P2 = mesh.tree_node_coordinates[:, nnodes, nnodes, k]
P3 = mesh.tree_node_coordinates[:, 1 , nnodes, k]
# compute the four side lengths and get the smallest
L0 = sqrt( sum( (P1-P0).^2 ) )
L1 = sqrt( sum( (P2-P1).^2 ) )
L2 = sqrt( sum( (P3-P2).^2 ) )
L3 = sqrt( sum( (P0-P3).^2 ) )
h = min( L0, L1, L2, L3 )
println(h)
end
Does anyone see any reason not to make this length-based AMR the default? If possible, feasible, and sensible, I'd like to have only one concept of specifying the maximum refinement, but I see potential conflicts between generalization (h-based refinement) and simplicity (ah, I just specify a minimum and maximum level and do not care about lengths etc.)
If we switch to allowing only a length-based version, it will be a breaking change (fine for me, but needs to be handled correctly). Might be worth benchmarking a bit to see whether there are any significant performance differences.
In principle, I would personally like to have the AMR controlled via LEVELS - as this is much easier to handle, as no special thought has to be made about the correct value of "h" (which might be a bit tedious depending on the setup).
I would use the h - controller only for the unstructured mesh, as a special case. If the unstructured mesh is about regular, the level - contoller is fine and imo preferable.
only when using a real unstructured irregular mesh in the beginning...then I would switch over to the h - controller.
For a real iregular unstructured mesh, I wonder if the length of the sides is a good measure for the size "h" of the element. Furthermore, I would make the maximum in any case, as the accuracy is typically linked to the largest "h" (if no special anisotropic amr is used).
I wonder for instance, if the maximum diagonal size could be a good measure instead? The maximum length of the element sides would be on the other hand consistent to the Cartesian tree mesh AMR.
Also, how about the extension to 1D (not important) and 3D (important)?
For a real iregular unstructured mesh, I wonder if the length of the sides is a good measure for the size "h" of the element.
This is somewhat related to what makes a "good" quad element. There are different measures for how "large" an element is that are found in the Verdict library. These are the kinds of measurements that HOHQMesh
outputs as statistics. We could experiment with different size measures and how they influence the AMR controller, maybe on two meshes like the cylinder channel flow (an "easy" geometry) and the gingerbread man (a "hard" geometry).
Yeah, experimenting with different measures and settling on one of them as default sounds reasonable. If possible, it would of course be nice to have something that's somewhat "dimension independent".
If possible, it would of course be nice to have something that's somewhat "dimension independent".
The Verdict library (and HOHQMesh) also has hex element statistics that we can experiment with. Then we could write a function called something like compute_initial_element_sizes
that dispatches on the dimension.
In principle, I would personally like to have the AMR controlled via LEVELS - as this is much easier to handle, as no special thought has to be made about the correct value of "h" (which might be a bit tedious depending on the setup).
I would use the h - controller only for the unstructured mesh, as a special case. If the unstructured mesh is about regular, the level - contoller is fine and imo preferable.
only when using a real unstructured irregular mesh in the beginning...then I would switch over to the h - controller.
Maybe you're right 🤷
A new type of AMR controller would be a good to have for unstructured meshes. Such a controller would incorporate the relative element size
h
measured in some way (e.g. smallest side length, aspect ratio, Jacobian, etc). Also a smallesth
size should be specified similar to setting thebase_level
in the current controller. Theseh
values would then be used during the computation of atarget_level
and assist in the decision of whether or not an element be refined / coarsened.