On Wed, 24 May 2017, Salazar De Troya, Miguel wrote: > For refinement of constant monomial elements, the GenericProjector > directly copies the value from the parent > (https://github.com/libMesh/libmesh/blob/master/src/systems/system_projection.C#L1236) > However for coarsening there is no such an optimization and the > algorithm builds the shape functions, calculate inverse maps, etc. > instead of just calculating the average among the children elements.
> Is there any specific reason for this? A total rationalization: child elements may be different sizes, which means we would need to take volumes to do a weighted average, which starts to get up towards the cost of just using the generic implementation. A more honest reason: simpler code is preferable, all other things equal, so we often don't add complicated optimizations until profiling shows a benefit. Nobody's done that much adaptive coarsening of monomials yet, I suppose. The most honest reason: programmer-hours are much, much more precious than CPU-hours. If someone put in a patch with that optimization we'd probably take it, but if someone's looking to optimize AMR there are many more low-hanging fruits to pick. "Why are we doing maps and inverse map rather than computing parent<->child translations directly in master element space?" would be at the top of my list; a facility for improving that would be a big optimization in hanging node code too. --- Roy ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
