# Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

## Re: [Libmesh-devel] Implicit assumption

 Re: [Libmesh-devel] Implicit assumption From: Benjamin S. Kirk - 2004-06-08 02:45:43 ```Yes, the element node numbering corresponds to the local dof numbering. DOFs are first assigned to the nodes of the element, and then to the element itself. Strictly speaking, ex3 is more correct. It forms the proper L2 projection matrix for each node on the boundary. A "shortcut" is made in ex10 in which we "lump" the mass (projection) matrix. Also, in this example, linear elements are used. In this case each node has a DOF, and the local DOF numbering corresponds to the local node numbering. Note ex10 should break if you use linear approximation on a QUAD8 element, for instance, since the mid-face nodes have no DOFS. In that case the code in ex3 is correct. I should probably change it to be consistent... In the case that a node lives on n sides (e.g. n=2, a corner in 2D) then either case will have a similar effect: It adds an identical row to the matrix n times and adds n (possibly) different RHS values. The net effect is to assign the node the average value of all the Dirichlet values it touches. In general, the element node (and hence local DOF) numbering is designed to be nested... That way only the new nodes introduced in a higher-order element need to be numbered. This has strengths & weaknesses... Clearly a HEX64 numbered like this would be confusing! Anyway, the local DOFs are assigned to nodes first, then to the element itself. Finally, there is a more "conventional" way to assign Dirichlet BCs in the case of lagrange elements, but it requires more "if" tests. Basically, the problem is that it is possible for an element to have a node with a BC even if it has no sides on the boundary (especially triangles, tets). In this case you must test every node in the element, not just sides on the boundary. We have found penalty to work quite well, but if you want more info on the more "standard" treatment let me know. Note that the L2 projection brought in by the penalty approach is particularly appealing when you do not have a nodal basis, like in the case of the hierarchics... -Ben Ahmed EL-Sheikh wrote: > I am wondering if this is correct... > > There is a implicit assumption of the DOF numbering for an element. > Where the local node numbering corresponds to the element local > degree of freedom. ( I checked DofMap::dof_indices) > > So this why the Dirichlet boundary conditions applied in ex10 > works, where n is the node number and Ke(n,n) and Fe(n,n) > are the corresponding contributions for the penalty function. > > Following up of the same subject of Dirichlet BC on > example 3 where there is a different treatment. > Where we find > > for (unsigned int i=0; i for (unsigned int j=0; j Ke(i,j) += JxW_face[qp]*penalty*phi_face[i][qp]*phi_face[j][qp]; > > // Right-hand-side contribution of the L2 > // projection. > for (unsigned int i=0; i Fe(i) += JxW_face[qp]*penalty*value*phi_face[i][qp]; > > > Is there any possible case when i is not equal to j and > K(i,j) have a value. Or that we are re-adding Fe(0) on > each face. Say if the element have two NULL neighbors. > > Ahmed > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```

 [Libmesh-devel] Implicit assumption From: Ahmed EL-Sheikh - 2004-06-07 23:21:36 ```I am wondering if this is correct... There is a implicit assumption of the DOF numbering for an element. Where the local node numbering corresponds to the element local degree of freedom. ( I checked DofMap::dof_indices) So this why the Dirichlet boundary conditions applied in ex10 works, where n is the node number and Ke(n,n) and Fe(n,n) are the corresponding contributions for the penalty function. Following up of the same subject of Dirichlet BC on example 3 where there is a different treatment. Where we find for (unsigned int i=0; i
 Re: [Libmesh-devel] Implicit assumption From: Benjamin S. Kirk - 2004-06-08 02:45:43 ```Yes, the element node numbering corresponds to the local dof numbering. DOFs are first assigned to the nodes of the element, and then to the element itself. Strictly speaking, ex3 is more correct. It forms the proper L2 projection matrix for each node on the boundary. A "shortcut" is made in ex10 in which we "lump" the mass (projection) matrix. Also, in this example, linear elements are used. In this case each node has a DOF, and the local DOF numbering corresponds to the local node numbering. Note ex10 should break if you use linear approximation on a QUAD8 element, for instance, since the mid-face nodes have no DOFS. In that case the code in ex3 is correct. I should probably change it to be consistent... In the case that a node lives on n sides (e.g. n=2, a corner in 2D) then either case will have a similar effect: It adds an identical row to the matrix n times and adds n (possibly) different RHS values. The net effect is to assign the node the average value of all the Dirichlet values it touches. In general, the element node (and hence local DOF) numbering is designed to be nested... That way only the new nodes introduced in a higher-order element need to be numbered. This has strengths & weaknesses... Clearly a HEX64 numbered like this would be confusing! Anyway, the local DOFs are assigned to nodes first, then to the element itself. Finally, there is a more "conventional" way to assign Dirichlet BCs in the case of lagrange elements, but it requires more "if" tests. Basically, the problem is that it is possible for an element to have a node with a BC even if it has no sides on the boundary (especially triangles, tets). In this case you must test every node in the element, not just sides on the boundary. We have found penalty to work quite well, but if you want more info on the more "standard" treatment let me know. Note that the L2 projection brought in by the penalty approach is particularly appealing when you do not have a nodal basis, like in the case of the hierarchics... -Ben Ahmed EL-Sheikh wrote: > I am wondering if this is correct... > > There is a implicit assumption of the DOF numbering for an element. > Where the local node numbering corresponds to the element local > degree of freedom. ( I checked DofMap::dof_indices) > > So this why the Dirichlet boundary conditions applied in ex10 > works, where n is the node number and Ke(n,n) and Fe(n,n) > are the corresponding contributions for the penalty function. > > Following up of the same subject of Dirichlet BC on > example 3 where there is a different treatment. > Where we find > > for (unsigned int i=0; i for (unsigned int j=0; j Ke(i,j) += JxW_face[qp]*penalty*phi_face[i][qp]*phi_face[j][qp]; > > // Right-hand-side contribution of the L2 > // projection. > for (unsigned int i=0; i Fe(i) += JxW_face[qp]*penalty*value*phi_face[i][qp]; > > > Is there any possible case when i is not equal to j and > K(i,j) have a value. Or that we are re-adding Fe(0) on > each face. Say if the element have two NULL neighbors. > > Ahmed > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```