Re: [Libmesh-users] DG implementation

[Rossi, S. <sr...@em...>]

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 <roy...@ic...> 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