## Re: [Libmesh-devel] Derivative evaluations on manifolds

 Re: [Libmesh-devel] Derivative evaluations on manifolds From: Roy Stogner - 2011-06-17 01:36:07 ``` On Thu, 16 Jun 2011, Derek Gaston wrote: > we use dphi and d2phi for 1D elements in 2D all the time as well. > Are you sure it's wrong... Pretty sure. "dphi[i][p](1) = 0." doesn't leave a lot of room for uncertainty. > because we're definitely getting the > right answers... even for analytic solutions. Depending on your formulation (and on the mesh - straight would be safer than curved, for example) it would be possible to for a code to generate the wrong gradients but still leave you with a formulation with the right answers. But I would *very much* like to know that you're still getting the right analytic solutions with r4611. That looks mathematically correct and it fixed the problems with our app code, but I haven't run any benchmark problems on it yet. > I don't have time to check for myself right now... but I'll > certainly investigate more on Monday. Thanks! --- Roy ```

 [Libmesh-devel] Derivative evaluations on manifolds From: Roy Stogner - 2011-06-16 21:30:17 ```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 ```
 Re: [Libmesh-devel] Derivative evaluations on manifolds From: Roy Stogner - 2011-06-16 22:03:43 ```On Thu, 16 Jun 2011, Roy Stogner wrote: > Does libMesh not calculate dphi and d2phi properly for > lower-dimensional elements embedded at odd angles in > higher-dimensional spaces? Things might not be as bad as I thought - it looks like the 2D-embedded-in-3D code was correct, just the 1D-embedded in 2D/3D code was incomplete? --- Roy ```
 Re: [Libmesh-devel] Derivative evaluations on manifolds From: Derek Gaston - 2011-06-16 23:20:23 ```Ok good! Because we use 2D in 3D all the time.... and actually now that I think about it we use dphi and d2phi for 1D elements in 2D all the time as well. Are you sure it's wrong... because we're definitely getting the right answers... even for analytic solutions. I don't have time to check for myself right now... but I'll certainly investigate more on Monday. Derek On Jun 16, 2011, at 4:03 PM, Roy Stogner wrote: > > On Thu, 16 Jun 2011, Roy Stogner wrote: > >> Does libMesh not calculate dphi and d2phi properly for >> lower-dimensional elements embedded at odd angles in >> higher-dimensional spaces? > > Things might not be as bad as I thought - it looks like the > 2D-embedded-in-3D code was correct, just the 1D-embedded in 2D/3D code > was incomplete? > --- > 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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] Derivative evaluations on manifolds From: Roy Stogner - 2011-06-17 01:36:07 ``` On Thu, 16 Jun 2011, Derek Gaston wrote: > we use dphi and d2phi for 1D elements in 2D all the time as well. > Are you sure it's wrong... Pretty sure. "dphi[i][p](1) = 0." doesn't leave a lot of room for uncertainty. > because we're definitely getting the > right answers... even for analytic solutions. Depending on your formulation (and on the mesh - straight would be safer than curved, for example) it would be possible to for a code to generate the wrong gradients but still leave you with a formulation with the right answers. But I would *very much* like to know that you're still getting the right analytic solutions with r4611. That looks mathematically correct and it fixed the problems with our app code, but I haven't run any benchmark problems on it yet. > I don't have time to check for myself right now... but I'll > certainly investigate more on Monday. Thanks! --- Roy ```
 Re: [Libmesh-devel] Derivative evaluations on manifolds From: Derek Gaston - 2011-06-17 02:28:02 ```Wow - we'll certainly run the full suite of tests on Monday (and maybe create a few new ones!). Thanks for catching this and fixing it! Derek On Jun 16, 2011, at 7:35 PM, Roy Stogner wrote: > > > On Thu, 16 Jun 2011, Derek Gaston wrote: > >> we use dphi and d2phi for 1D elements in 2D all the time as well. >> Are you sure it's wrong... > > Pretty sure. "dphi[i][p](1) = 0." doesn't leave a lot of room for > uncertainty. > >> because we're definitely getting the >> right answers... even for analytic solutions. > > Depending on your formulation (and on the mesh - straight would be > safer than curved, for example) it would be possible to for a code > to generate the wrong gradients but still leave you with a formulation > with the right answers. > > But I would *very much* like to know that you're still getting the > right analytic solutions with r4611. That looks mathematically > correct and it fixed the problems with our app code, but I haven't run > any benchmark problems on it yet. > >> I don't have time to check for myself right now... but I'll >> certainly investigate more on Monday. > > Thanks! > --- > Roy ```