From: Laura S. <sca...@ma...> - 2018-02-05 09:01:36
|
Hi Roy, Thank you for the answer. Yeah, I meant the second option, that is that ``the hanging nodes don't fit the pattern of "coarse element with isotropically refined neighbor"". I just wanted to get a clue on how difficult it would have been to implement this case with libmesh. Then, according to your answer, it would require quite some time. Thank you again, Laura. Il 2018-02-03 17:19 Roy Stogner ha scritto: > On Sat, 3 Feb 2018, Laura Scarabosio wrote: > >> I apologize for the simple question but I could not find satisfactory >> answers on the web. > > I'm not surprised; I think the most relevant discussion was just a > week ago: > > https://sourceforge.net/p/libmesh/mailman/message/36202144/ > > and even if we managed to hit whatever keywords you were searching > for, it probably doesn't get ranked highly by search engines yet. > >> Does libMesh support meshes with hanging nodes when these are used >> right away and do not come from a libMesh refinement of a mesh without >> hanging nodes? >> I mean, is calling dof_map.constrain_element_matrix_and_vector enough >> to handle this case, too? > > It depends what you mean by "used right away": > > If the hanging nodes come from a libMesh-*style* refinement (isotropic > refinement of a parent element), then libMesh will auto-generate > constraint equations for them, even if you're just loading the refined > mesh from a saved or handwritten file rather than using libMesh > refinement code. > > However, if the hanging nodes don't fit the pattern of "coarse > element with isotropically refined neighbor", libMesh will not > auto-generate constraint equations. You could still define systems on > such a mesh, but you'd have to add constraint equations manually to > get solves to work, you'd have to add ghosting functors to get > DistributedMesh to work, you'd have to add jump terms to error > estimators by hand, and in general it would be a huge pain in the > neck. > --- > Roy |