Hi Lei, I'll try to answer to some of your questions since I wrote this dG example. In general it is not easy to identify which is the most expensive portion of a code and libMesh developers make extensive use of profiling tools. Something might be inefficient in your specific application but efficiency concerns imply that you have something to compare with.
> > In this example, the Laplace equation is solved using DG with interior > penalty method. So the main job is to compute the mass matrix from the > element volume integration and surface jump integration. It is done element > by element with the help of element iterator. I know all of the elements > organized as a quad-forest and only the active items need to be looped. I guess you mean stiffness matrix. > > so does this mean when we need to reach to the next active element, > const_element_iterator++ need to go through the quad-forest and pass several > non-active parent elements then get to the correct element pointer to the > next active element? If the answer is true. Is it too expensive to find an > element in a solver? > > The other thing is the metrics computing such as Jacobian, xi_x xi_y eta_x > eta_y and face normal etc. Do those metrics computed several times using > FE::FEMap? If the mesh is fixed in space, we only need to compute them once > and store them somewhere. > > Same thing happens when computing quadrature points in physical domain and > value of shape function/ its derivation at those points in computational > domain. I think those are computed in > ---------------------- > fe->reinit(elem) > ---------------------- > Those values do not change during the calculation and should be computed only > once. I think they are in the deepest loop and will eat a lot of cpu time. > You can always store quantities that you need several times but this might eat up a lot of memory. Accessing to memory might be expensive and sometimes it might be even faster to recompute. The libMesh approach is to recompute everything. In your application you might store something but, when the problem you need to solve reaches a critical size, you want to store quantities that are really expensive to compute. I think that one important point is time integration. In explicit solvers assembly times dominates and it might be useful to store FE related quantities. In implicit solvers usually the memory is used to store the global system matrix, the preconditioner ecc... > Last one, to compute the flux jump at flux points on the common surface of > two cells with different h levels. The coordinates and normals of the flux > quadrature points on the both side of element are computed several times if > we use a residual based scheme. It does not change at each refinement level. > Is there any efficient way to handle those kind of situation: flux jump > calculation at a surface with hanging node? When you do h-refinement the calculation of interface quantities is actually more expensive since you need to find matching quadrature points on the sides of neighboring elements. If you use reference frame basis functions starting from a physical frame quadrature point you need to find the corresponding reference frame quadrature point on the neighbor. This requires to invert the reference to physical frame map by means of the Newton method. > > Or those are just for demo only. Those efficiency problem get even worse for > a scheme need residual jacobian at each time step. Do we need to use FEMap > explicitly and store the metrics for each element/face? So we don't need to > compute them more than once. This is just a demo that make sense for the Laplace equation and it shows how to compute the quantities you need. If you want to store quantities you will need to care care of that. > > Thanks a lot for your time. Greetings Lorenzo > > > > Sincerely Yours, > > Lei Shi > ---------- > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Libmesh-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
