The problem the I see with using a system with LAGRANGE variables is that the code for assembling the element stiffness matrix becomes a bit messy and less flexible to switch from 2 to 3 dimensions and vice versa.
For instance, in the example https://github.com/libMesh/libmesh/blob/master/examples/systems_of_equation s/systems_of_equations_ex6/systems_of_equations_ex6.C#L181 I think DenseSubMatrix<Number> Ke_var[3][3] could be changed to be an array of arrays to pointers and making them point to the corresponding jacobians by calling the context as in https://github.com/libMesh/libmesh/blob/master/examples/fem_system/fem_syst em_ex3/elasticity_system.C#L102 Are there other prettier ways or more modern ways to implement a code that can change from 2 to 3 dimensions in runtime? Thanks Miguel On 8/4/16, 11:26 AM, "Roy Stogner" <royst...@ices.utexas.edu> wrote: > >On Wed, 3 Aug 2016, Salazar De Troya, Miguel wrote: > >> where coef is the vector with the element components of the >> solution. The problem that I see here is that for the LAGRANGE >> element, dphi[l][qp] is a RealGradient with mostly zeros and it¹s >> the same information for shape functions on the same node but >> different vector component. > >Yup. This is one reason why we typically manually use multiple >LAGRANGE variables rather than a single LAGRANGE_VEC variable when >solving problems for which a tensor product finite element space is >adequate. The vector-valued finite elements are intended more for >cases where you want H(curl) or other exotic vector elements that >can't be expressed as tensor products of scalar elements. >LAGRANGE_VEC currently just exists for debugging purposes IMHO. > >That being said, two items I'm getting funded for next fiscal year are >"vector-valued element support" (i.e. bringing it from "technically >exists" to "can be used for all the same library features that >scalar-valued elements support") and "optimization", so I'm sure the >intersection of the two will get some attention too. > >> (xx,xy,xz)=(-0.252376, -0.252376, -0) >> >> (yx,yy,yz)=( 0, 0, 0) >> >> (zx,zy,zz)=( 0, 0, 0) >> >> >> (xx,xy,xz)=( 0, 0, 0) >> >> (yx,yy,yz)=(-0.252376, -0.252376, -0) >> >> (zx,zy,zz)=( 0, 0, 0) >> >> If there was a way to, first use only one shape function for the >> degrees of freedom in the node (would mean four shape functions >> instead of eight for the case above) and second, avoid the zeros, >> would this significantly save computational resources? If no, why? > >You can get rid of ten of those zeros by recompiling with >LIBMESH_DIM==2, in a pinch. > >The trouble with the remaining 50% sparsity (and with the analogous >66% sparsity in 3D) is that it's LAGRANGE_VEC specific; dphi is dense >for other vector elements. It's hard to figure out an API which >optimizes in the sparse case without pessimizing in the dense case. > >I have actually done that successfully in one code, but I'm not sure >how easy it would be to integrate into libMesh. >--- >Roy ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
