So here's an embarrassing question from me: Does libMesh not calculate dphi and d2phi properly for lower-dimensional elements embedded at odd angles in higher-dimensional spaces?
I always assumed that worked (despite having edited the code myself...), and I even vaguely recall telling someone else that it probably worked, but until now I've only solved zeroth-order systems on BoundaryMeshes. Now I'm trying a simple poisson type problem, and I'm noticing that FEBase::compute_shape_functions() doesn't seem to be at all designed for the case where a 1D element lives in 2D space or a 2D element lives in 3D space. fe_base.C:708 could be calculating dphi = infinity for an edge in the yz plane! We seem to be doing everything correctly in compute_map(): dxidy_map and dxidz_map get calculated for 1D elements, for example... so is there any reason why we're not using these terms to do things right in cases where they're non-zero? Unless there's something I'm missing, I'd like to implement the correct dphi/d2phi calculations in compute_shape_functions. They are extra usually-unnecessary computations in 1D and 2D problems, so anyone objects for efficiency reasons scream now. My personal philosophy is a mix of "lower-dimensional problems are usually cheap to begin with" and "if you want them cheaper you can always use a --enable-2D-only or --enable-1D-only configure", but I'm open to being reasoned with. ;-) --- Roy ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
