## libmesh-devel

 [Libmesh-devel] C1 elements, second derivatives From: Roy Stogner - 2005-01-13 23:41:20 ```I've just finished committing the last chunks of my support for fourth-order problems to libMesh. The features: With the "--enable-second" configure option turned on, you can now query finite element objects for second derivative information, expressed as rank 2 tensors. With this you should be able to formulate discontinuous Galerkin approximations to fourth-order problems. You can now create Clough-Tocher macrotriangles (and the quadrature rules to integrate them properly), which form C1-differentiable (and so H2 conforming) finite element spaces. With these, assuming --enable-second is on, you can formulate continuous Galerkin approximations to 2D fourth-order problems. Example 15 (remember to "cvs update -d" to get new directories) demonstrates, using the biharmonic equation. The nonfeatures: Since only the C1 elements let you solve fourth-order problems easily, I've only added second derivative calculations to the other finite element classes where it was easy to do so - the rest are just stubs and warnings. Adding C1 infinite elements, in particular, looked like it would be ugly. The Clough-Tocher elements still work for second order problems with second derivative calculations off, but there's probably no point - they might be slightly more efficient than regular cubics in the solver but are certainly much less efficient in the assembly stage. Cubic triangles are the only C1 elements right now - I'm working on cubic quads and tets now, but it's not my top priority, and these things are a bear to code and debug. The problems: With "--enable-second" turned on, second derivatives are calculated and stored whether you need them or not - the memory hit is insignificant but I'll bet the speed hit is noticeable. In the long run we ought to have a method of making finite element reinit()s calculate precisely what each application code wants and no more; in the short run "--enable-second" ought to be left off unless you're using it. I've tested this code against my own applications and the libMesh examples, but since it makes low level additions to the FEBase class, I'm worried that it might work on my computer and break yours. Anyone working with the main CVS tree might want to pay extra attention to the next post-update run you make; anyone who wants to help might also try testing their own code with "--enable-second" too. --- Roy Stogner ```
 Re: [Libmesh-devel] C1 elements, second derivatives From: Benjamin S. Kirk - 2005-01-15 04:03:27 ```Thanks! I appreciate & welcome this significant addition to the code! I agree that reinit() should be a lot smarter. I think we could just put together a few bit flags here and avoid a lot of unnecessary computation. Thoughts? Also, ex10 looks broken. The initial solution is fine, but all the subsequent time steps look like the interior solution is 0 and the boundary conditions are then imposed. My guess is that the solution projection is having an issue? The solution snapshots in ex9 and ex10 should be the same, but it looks like the interior solution is all 0 in the case of ex10. -Ben Roy Stogner wrote: > > I've just finished committing the last chunks of my support for > fourth-order problems to libMesh. > > > The features: > > With the "--enable-second" configure option turned on, you can now > query finite element objects for second derivative information, > expressed as rank 2 tensors. With this you should be able to > formulate discontinuous Galerkin approximations to fourth-order > problems. > > You can now create Clough-Tocher macrotriangles (and the quadrature > rules to integrate them properly), which form C1-differentiable (and > so H2 conforming) finite element spaces. With these, assuming > --enable-second is on, you can formulate continuous Galerkin > approximations to 2D fourth-order problems. Example 15 (remember to > "cvs update -d" to get new directories) demonstrates, using the > biharmonic equation. > > > The nonfeatures: > > Since only the C1 elements let you solve fourth-order problems easily, > I've only added second derivative calculations to the other finite > element classes where it was easy to do so - the rest are just stubs > and warnings. Adding C1 infinite elements, in particular, looked like > it would be ugly. > > The Clough-Tocher elements still work for second order problems with > second derivative calculations off, but there's probably no point - > they might be slightly more efficient than regular cubics in the > solver but are certainly much less efficient in the assembly stage. > > Cubic triangles are the only C1 elements right now - I'm working on > cubic quads and tets now, but it's not my top priority, and these > things are a bear to code and debug. > > > The problems: > > With "--enable-second" turned on, second derivatives are calculated > and stored whether you need them or not - the memory hit is > insignificant but I'll bet the speed hit is noticeable. In the long > run we ought to have a method of making finite element reinit()s > calculate precisely what each application code wants and no more; in > the short run "--enable-second" ought to be left off unless you're > using it. > > I've tested this code against my own applications and the libMesh > examples, but since it makes low level additions to the FEBase class, > I'm worried that it might work on my computer and break yours. > Anyone working with the main CVS tree might want to pay extra > attention to the next post-update run you make; anyone who wants to > help might also try testing their own code with "--enable-second" too. > --- > Roy Stogner > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] C1 elements, second derivatives From: Roy Stogner - 2005-01-15 17:28:12 ```On Fri, 14 Jan 2005, Benjamin S. Kirk wrote: > Thanks! I appreciate & welcome this significant addition to the code! Oh, good. I was a little antsy about committing a few thousand new lines on one day, but since (except for System::project_vector, which I'd just forgotten to commit earlier) it was all infrastructure for the same use, it's hard to break up into independently testable chunks. I think John and you are right that we should be making the "what derivatives to compute" choice at runtime, not configure time, too, but figured the most incremental way for me to commit my code was to start it out #ifdef'ed out of other people's binaries. > I agree that reinit() should be a lot smarter. I think we could just put > together a few bit flags here and avoid a lot of unnecessary computation. > Thoughts? A flags object is the way deal.ii does it, and that works just fine. We could have the default state of the flags be "compute function values and first derivatives" to keep old code working efficiently, and even new (or updated) second order code might be sped up a little bit by not calculating any derivatives on Dirichlet faces. I've been trying to figure out some way to make this decision automatically, based on what get_phi, get_dphi, etc. calls have been made recently. Such calls could return an object whose constructor tells the finite element "compute me" and whose destructor tells it "stop computing me". We could even write a conversion operator that turns this new object into the usual "vector of vector of gradients/numbers/tensors" and tells the finite element "never stop computing me", for source compatibility with older code. This is starting to sound more complicated than it's worth, though. > Also, ex10 looks broken. The initial solution is fine, but all the > subsequent time steps look like the interior solution is 0 and the boundary > conditions are then imposed. My guess is that the solution projection is > having an issue? The solution snapshots in ex9 and ex10 should be the same, > but it looks like the interior solution is all 0 in the case of ex10. You're right - the Lagrange elements case of my new Solution::project_vector is failing. I forgot a new_vector.close() statement at the end, but fixing that wasn't sufficient. Making the "if != LAGRANGE" test into an "if true" test and thus using the L2 projection for every element seems to work (although on ex10, the total project_vector time then becomes 14 seconds instead of 6 on my machine). Obviously, using the old interpolation code works. My attempt to merge the two appears to be what's failed. We could fix this by just restoring most of the old function and handing off to it for the lagrange case, but there's a lot of redundancy between the two and I'd like to keep them merged if it can be done correctly. I'll try and fix it today, and revert the CVS head to the old version tomorrow if I can't find the problem. --- Roy Stogner ```
 Re: [Libmesh-devel] C1 elements, second derivatives From: Roy Stogner - 2005-01-17 02:38:54 ```On Fri, 14 Jan 2005, Benjamin S. Kirk wrote: > Also, ex10 looks broken. The initial solution is fine, but all the > subsequent time steps look like the interior solution is 0 and the boundary > conditions are then imposed. My guess is that the solution projection is > having an issue? The solution snapshots in ex9 and ex10 should be the same, > but it looks like the interior solution is all 0 in the case of ex10. I think I've found the problem - When revisiting a DoF from a new element I didn't recalculate it, but I did reset it, to zero. Would you take a look at the fix when you have time? Thanks, --- Roy Stogner ```