Dear Roy, thanks for your reply. I was worried about the ordering because the exported solution did not make sense. It seemed to apply the boundary conditions to the wrong elements. I learned that the global ordering is general different for different fefamilies, but everything is consistent. I just was not expecting a different ordering, as I always used the continuous elements in libmesh.
In my simple test I had a mesh like this. Using both monomials and l2_lagrange ,I was getting 6 dof for each component of the system (2 in 2D, so the 12 entries). X ————X | / | | / | | / | | / | | / | X———— X Eventually I found out that the way I’m using the exodus exporter with discontinuous data is not correct. So if I do exo_exporter->write_discontinuous_exodusII( … ) exo_exporter->append(true) and then exo_exporter->write_timestep( … ) the exported file is messed up. Is there any other way to do that with exodus? I ended up using GMV, but I loose the time information. Thanks a lot, All the best, Simone On Feb 10, 2017, at 10:01, Roy Stogner <[email protected]> wrote: > > > On Thu, 9 Feb 2017, Rossi, Simone wrote: > >> Additionally I noticed something wrong in the assembly. >> When I use LAGRANGE fefamily my global rhs vector (for a 2D elasticity >> problem) looks like this >> >> u_x_point0 >> u_y_point0 >> >> u_x_point1 >> u_y_point1 >> >> . >> . >> . >> >> u_x_pointN >> u_y_pointN >> >> and the local vector is organized in the following manner >> >> u_x_point0 >> u_x_point1 >> u_x_point2 >> >> u_y_point0 >> u_y_point1 >> u_y_point2 > > DoF ordering isn't "right" or "wrong", it's a design decision. With > libMesh the local vector ordering is fixed (that's what lets us use > DenseSubMatrix which has only an offset and not a stride to worry > about); the global vector ordering should be either (processor, node, > variable) or (processor, variable, node) depending on whether you use > --node_major_dofs or not. > >> Does this still happen with other fefamilies? > > With more interesting FE types, and adaptive p refinement, and > adaptive h refinement with hanging nodes (which may conjoin vertex > with side/edge degrees of freedom or may only couple them via > constraint equations, depending on FE type), global DoF ordering can > do much more complicated things, and trying to second-guess it at the > application level will just leave you with incompatibilities at best > or bugs at worst. Just use the local vectors, with submatrices and > subvectors to index into them. > >> My routine for assembly of traction boundary conditions works with >> LAGRANGE fefamily. For a 2D square with 2 elements > > Two elements, each with 4 degrees of freedom, but not actually sharing > any nodes so that's you end up with 8 degrees of freedom in the full > system? > > But then you'd have 6 degrees of freedom with MONOMIAL or 8 with > L2_LAGRANGE elements, not 12. I need more detailed description here. > --- > Roy ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
