On Sat, 11 Jan 2020, Bin Liu wrote:
> John mentioned about MOOSE library, which is built on top of > libmesh. Does MOOSE library make use of > "libMesh::DifferentiablePhysics" class? It seems MOOSE library can > deal with the multi-physics problems with dynamic mesh in libmesh > library quite well. By the way, while sub-dividing an element based > on the coordinates extracted by "elem->point()", I noticed that the > truncation error of the coordinates of element nodes is relative > large. Please correct me, if I am wrong about this. We do use a generic algorithm in ElemRefinement, so instead of calculating e.g. new_HEX8_node = sum(two_neighboring_edge_nodes)/2 we calculate sum(coefficient_i * element_node_i) for all 8 nodes i, which you'd expect to have four times the floating point error ... but 16 times epsilon is still *really* small, and I believe most of our Lagrange shape functions actually come out exact at new node points, in which case there'd be no difference at all in those cases. > Could it be the reason to affect the convergence rate? This seems even more unlikely to be noticeable. Finite Element methods work even when you don't perfectly subdivide elements (as some mesh refinement styles don't, e.g. when smoothly grading into boundary layers). An epsilon difference in child element sizes will just mean that your hmax dropped by .5+epsilon rather than .5, which will mean an epsilon difference in convergence rates, unless you're specifically using some superconverence reconstruction trick that depends on exactly equispaced meshes. But all that is about what our element subdivision *should* do, not what it does do. Could you give a counter-example? Do note that if you're just printing out elem->point(), unless you've specifically increased the stream precision() you'll be seeing output that's much more truncated on the screen than it is in memory. We actually had bugs in some of our ASCII I/O formats due to this, years and years ago, when we forgot to increase precision before writing the output files. --- Roy _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
