Re: [Libmesh-users] DG implementation
Dear John, thanks for your reply. I’m attaching a simple test with 2 elements in which I define a system with a single variable using first order elements of l2_lagrange family. I initialize the variable so that each degree of freedom stores its own ID. If I use write_discontinuous _exodusII(), the solution is exported correctly. If after that I export another timestep, I get some wrong values. I should also mention that I’m using Paraview to visualize the data. Thank you very much, Best, Simone -- 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] DG implementation
On Fri, Feb 10, 2017 at 2:43 PM, Rossi, Simone wrote: > Dear John, > thanks for your reply. > I’m attaching a simple test with 2 elements in which I define a system > with a single variable using first order elements of l2_lagrange family. > I initialize the variable so that each degree of freedom stores its own ID. > > If I use write_discontinuous _exodusII(), the solution is exported > correctly. If after that I export another timestep, I get some wrong values. > I believe the problem here is that ExodusII_IO::write_timestep() just calls write_equation_systems(), while write_discontinuous_exodusII() follows a different code path entirely. If you are writing out discontinuous data I don't believe you should be calling the former at all. This raises the question of how to write multiple discontinuous data sets to a single file... this may not currently be supported. In the meantime, a workaround might be to call write_discontinuous_exodusII() each timestep with and write files with the following naming convention. dg.e-s dg.e-s0001 dg.e-s0002 ... Paraview should then be able to read and display these results in a time sequence. -- John -- 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] DG implementation
On Fri, Feb 10, 2017 at 9:11 AM, Rossi, Simone wrote: > 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. > It's possible that write_discontinuous_exodusII() has regressed, we test that it "works" in miscellaneous_ex5 and systems_of_equations_ex6, but don't do any gold file comparisons... If it's possible for you to share a very simple (2 element) example like this which demonstrates the problem, we can take a closer look... -- John -- 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] DG implementation
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 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] DG implementation
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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] DG implementation
Dear all, I’m trying to implement a DG formulation for solid mechanics using linear elements. I’m currently using the following strategy: I define my variables as MONOMIALS but in the assembly I pretend my FEType is LAGRANGE. This gives me the correct values of the shape functions on the edges. I was also able to use the L2_LAGRANGE family to achieve the same results. Do you have any suggestions on which family I should use? 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 Does this still happen with other fefamilies? My routine for assembly of traction boundary conditions works with LAGRANGE fefamily. For a 2D square with 2 elements and a shear traction condition my rhs is RHS! Sizeglobal = 8 local = 8 # Value 0 0 1 0 2 0 3 3.125 4 0 5 3.125 6 0 7 0 When using MONOMIALS or L2_LAGRANGE , I think the contributions are in the wrong places RHS! Sizeglobal = 12local = 12 # Value 0 0 1 0 2 0 3 0 4 3.125 5 3.125 6 0 7 0 8 0 9 0 10 0 11 0 Does anyone have any suggestion? Thank you very much for your help, All the best, Simone -- 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
