## Re: [Libmesh-devel] Derivatives on hierarchic elements

 Re: [Libmesh-devel] Derivatives on hierarchic elements From: Roy Stogner - 2011-02-09 17:26:12 ```On Fri, 4 Feb 2011, Saurabh Srivastava wrote: > I looked into the file and quite worried about this implementation, have you > followed any particular implementation of Hierarchics on triangles? I > presume the triangles are not trivial tensor product based and so analytical > derivatives are good effort to compute.. can you give me some > tips/references on what polynomials are used and how? No, but I'll Cc: this to libmesh-devel - I think it was Ben or John who put in the shape function implementations and hopefully they'll have a reference you could look at to make it easier to calculate derivatives. > I am also wondering how to statically link the library(both petsc and > libmesh) to my code?, based on the perflog I see that most of the time is > spent in linear solvers, which in a way is a good happening ... although it > takes few thousand iterations for only one linear solve / iteration/ time > step ..since conditioning is quite poor..but  there might be issue due to > time spent in linking on the fly for those thousand iterations? Nope - the cost of dynamic linking is pretty much all at the very start of run time when the linking is done. > I would like to use a parallel direct solver from petsc which I have > compiled with full set of solvers, umfpack, superlu etc.. but the command > line argument -mat_type superlu etc. all throw an error in petsc 3.1.4 as > unrecognized, so what is the command line way to use a parallel sparse > direct solver in libmesh? Off the top of my head: use the direct solver as a "preconditioner"; the Krylov loop will then terminate with a single iteration and you can replace GMRES with Richardson or something simple. You might want to check the performance of ILU4 or something intermediate before taking such a drastic step, though. --- Roy```

 [Libmesh-devel] Parallel AMR bugfix for Hierarchic (and other) elements From: Roy Stogner - 2010-11-09 00:12:44 ```On Mon, 8 Nov 2010, Roy Stogner wrote: > Indeed it does! I can replicate that (seeing an exception in the > ghosted vector support) just by switching ex14 to cubic hierarchics. > > I'll look into this ASAP. I rooted out the problem I found, and the bug fix for that is in the svn head now. Saurabh, would you test this with your own code in debug or devel mode and make sure that no further assertions are thrown? I can't reproduce any other errors myself yet, but, as you've had the misfortune to find out, it's been a little while since anyone's given the higher order HIERARCHICs a full shaking out. Some more info on the bug, for other developers interested: During the work on ghosted vectors, we did a little optimization on the DofMap send_list, so now it should contain only ghost dof IDs and not all semilocal IDs. When we removed the addition of local IDs, it also inadvertently removed the only place where a certain category of ghost DoF ID was added: IDs on hanging nodes might be inadvertently omitted if the finite element type had vertex DoFs that did not overlap their side/edge DoFs. So the bug affected Clough-Tocher elements, Hierarchics, and 4th-order-or-higher Hermites. The DofMap bug fix is in there now, but I'm going to wait for Saurabh's reply before putting out a libMesh 0.7.0.3. We also construct a different sort of send_list in independent code for System::project_vector, and although I couldn't find any bugs in that code, Saurabh first reported seeing a problem with projections, so maybe there's a failure case that I just haven't noticed or hit yet. This bug would have been a silent data-corrupting error if not for the extra tests in the ghosted vector code. Thanks again to Tim: if you're ever in Austin dinner is on me. --- Roy ```
 [Libmesh-devel] Derivatives on hierarchic elements From: Roy Stogner - 2011-01-24 22:38:16 ``` On Mon, 24 Jan 2011, Saurabh Srivastava wrote: > --- I'm using Hierarchic basis ...and I checked the second > derivatives for 1st order basis are between 1e-5 to 1e-11 at several > quadrature points which is though  small but non-zero. Indeed on > your suggestion when I changed the basis to Lagrangian i got exact > zeros. Yeah, grep through fe_hierarchic_shape_2D.C for "I have been lazy here". I never needed second derivatives on hierarchic elements for myself, but I didn't want to leave them completely unimplemented, so I just tossed in a central differencing of the first derivatives. That would still come out exactly zero for constant first derivatives, but on your triangles those aren't perfectly constant, because in that case the HIERARCHIC first derivatives are finite differenced too! I'll Cc: this to the mailing lists, in case any altruistic folks want to code up analytic derivative evaluations. Altruistic folks or self-interested folks - that finite differencing error is probably the limiting factor when we do p refinement on triangles or in 3D. --- Roy```
 Re: [Libmesh-devel] Derivatives on hierarchic elements From: Roy Stogner - 2011-02-09 17:26:12 ```On Fri, 4 Feb 2011, Saurabh Srivastava wrote: > I looked into the file and quite worried about this implementation, have you > followed any particular implementation of Hierarchics on triangles? I > presume the triangles are not trivial tensor product based and so analytical > derivatives are good effort to compute.. can you give me some > tips/references on what polynomials are used and how? No, but I'll Cc: this to libmesh-devel - I think it was Ben or John who put in the shape function implementations and hopefully they'll have a reference you could look at to make it easier to calculate derivatives. > I am also wondering how to statically link the library(both petsc and > libmesh) to my code?, based on the perflog I see that most of the time is > spent in linear solvers, which in a way is a good happening ... although it > takes few thousand iterations for only one linear solve / iteration/ time > step ..since conditioning is quite poor..but  there might be issue due to > time spent in linking on the fly for those thousand iterations? Nope - the cost of dynamic linking is pretty much all at the very start of run time when the linking is done. > I would like to use a parallel direct solver from petsc which I have > compiled with full set of solvers, umfpack, superlu etc.. but the command > line argument -mat_type superlu etc. all throw an error in petsc 3.1.4 as > unrecognized, so what is the command line way to use a parallel sparse > direct solver in libmesh? Off the top of my head: use the direct solver as a "preconditioner"; the Krylov loop will then terminate with a single iteration and you can replace GMRES with Richardson or something simple. You might want to check the performance of ILU4 or something intermediate before taking such a drastic step, though. --- Roy```
 Re: [Libmesh-devel] Derivatives on hierarchic elements From: David Knezevic - 2011-02-09 18:33:29 ```Just to follow up this point: >> I would like to use a parallel direct solver from petsc which I have >> compiled with full set of solvers, umfpack, superlu etc.. but the >> command >> line argument -mat_type superlu etc. all throw an error in petsc >> 3.1.4 as >> unrecognized, so what is the command line way to use a parallel sparse >> direct solver in libmesh? > I regularly use the command line options: -ksp_type preonly -pc_type lu -pc_factor_mat_solver_package umfpack to use a direct solver with libMesh/PETSc (this works for me with petsc 3.0.0-p12). To change the solver, you can change umfpack to mumps or superlu or whatever. Dave ```
 Re: [Libmesh-devel] Parallel AMR bugfix for Hierarchic (and other) elements From: Roy Stogner - 2010-11-15 20:15:40 ```On Mon, 8 Nov 2010, Roy Stogner wrote: > The DofMap bug fix is in there now, but I'm going to wait for > Saurabh's reply before putting out a libMesh 0.7.0.3. 0.7.0.3 is up on https://sourceforge.net/projects/libmesh/ now. Anyone using parallel AMR with Hierarchic, Clough-Tocher, or high-order Hermite elements should upgrade if you're currently using 0.7.0.2 or an earlier release. If you're using the SVN head post-Nov-8 rather than a tarball release then there's no need to change or update to get this bugfix. But SVN users shouldn't be disappointed; we promise we'll work on introducing all-new bugs as soon as possible. --- Roy ```