On Wed, 31 Mar 2010, Lorenzo Botti wrote: > Il giorno 30/mar/2010, alle ore 20.33, Roy Stogner ha scritto: > >> This means that the current project_vector() code is definitely buggy >> for the hp case, and it's possible that the constraint generation code >> (which uses the same p-hierarchic assumption) has the same problem. > > I think that everything should work fine in the hp case with monomials > (dG formulations) but let me double check it tomorrow.
I agree, but I'd definitely like to have confirmation or a counter-example, thanks. > If find_neighbors() works as expected (and of coarse it does) Bah, I'm only 99% sure about that. It works as well as we can test with SerialMesh, but find_neighbors() is a nasty function which ended up being the source of the adaptive coarsening bug with ParallelMesh. > we don't need constraint generation as any element dof is implicitly > related to the neighbors dofs. Right. > The hp case with C^0 function spaces is more complicated. > Usually high order C^0 (spectral) elements don't allow hp refinement > because of the non trivial treatment of elements interfaces and because > it affects the finely tuned sparsity pattern of the matrix. Also right. But libMesh *should* be an exception - the code is all there to get the sparsity pattern and constraint equations right (at least for some FE types), it's just not tested enough and it looks like the constraint equation construction is probably still buggy. --- Roy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
