Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Roy Stogner <roystgnr@ic...>  20050113 23:41:20

I've just finished committing the last chunks of my support for fourthorder problems to libMesh. The features: With the "enablesecond" 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 fourthorder problems. You can now create CloughTocher macrotriangles (and the quadrature rules to integrate them properly), which form C1differentiable (and so H2 conforming) finite element spaces. With these, assuming enablesecond is on, you can formulate continuous Galerkin approximations to 2D fourthorder 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 fourthorder 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 CloughTocher 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 "enablesecond" 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 "enablesecond" 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 postupdate run you make; anyone who wants to help might also try testing their own code with "enablesecond" too.  Roy Stogner 
From: Benjamin S. Kirk <benkirk@cf...>  20050115 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 > fourthorder problems to libMesh. > > > The features: > > With the "enablesecond" 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 fourthorder > problems. > > You can now create CloughTocher macrotriangles (and the quadrature > rules to integrate them properly), which form C1differentiable (and > so H2 conforming) finite element spaces. With these, assuming > enablesecond is on, you can formulate continuous Galerkin > approximations to 2D fourthorder 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 fourthorder 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 CloughTocher 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 "enablesecond" 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 "enablesecond" 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 postupdate run you make; anyone who wants to > help might also try testing their own code with "enablesecond" too. >  > Roy Stogner > > >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Roy Stogner <roystgnr@ic...>  20050115 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 
From: Roy Stogner <roystgnr@ic...>  20050117 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 