On Wed, 16 May 2012, Yusuke Sakamoto wrote: > I looked for the source of the error, and found that it is due to the > fact that I call Mesh::all_second_order() after refining the mesh by, > MeshRefinement::uniformly_refine (n_refinements). It corrupts the > internal data structure or something in EquationSystems object. It > doesn't even save the right solution when I call > EquationSystems.write(...). When I call all_second_order before refining > the mesh, everything works perfectly.
Hmm... indeed, it looks like all_second_order() is only implemented for "flat" meshes but doesn't even contain a libmesh_assert() testing for refinement. I don't have time to implement a refinement-compatible all_second_order() right now, but I can at least add that assert(). Thanks for looking into this. > I will implement a new function for integration over cylindrical domain > for error estimate. One thing I might suggest: although you can't use higher-order finite element types on a mesh of first-order Elems, you can use first-order finite elements on a mesh of second-order Elems, and the added cost should only be moderate in RAM and trivial in CPU time. You might try that if you're planning to run a mix of first-order and second-order problems on the same mesh. --- Roy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
