Roy Stogner
2017-05-24 16:18:08 UTC
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, whichdirectly 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?
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