From: Lorenzo Botti <bottilorenzo@gm...>  20090611 20:21:49

I also had some problems with inverse mapping on second order geometries.The problem was related with the initial zero guess for the inverse mapped point, this caused the newton method to converge to a point outside the reference element resulting in a negative jacobian. At the beginning I had thought of an element with an extremely concave side and rebuilt the mesh several times. Maybe a call to the method on_reference_element() could help. Anyway this procedure should fix the performance issue for the boundary side integration of CG formulations. 1) search for the elem local nodes indices on the side (they are stored in side_nodes_map).2) use a method that returns reference space nodes coordinates for the element. 3) map the side quadrature points on the element's side using reference space coordinates. Nodes ordering match map ordering. On point 3 we can use the mapping (lagrangian basis function on side quadrature points) we have already computed. The major problem is internal side integration on nonconforming meshes for DG. After some tests I've found a method that works on level one nonconforming meshes. The procedure is complicated (especially for tets) and probably slower than inverse mapping in the perspective of a recursive call on arbitrary h refined meshes. Inverse map is general and what I'm suggesting isn't. I let you know if I find something better. Lorenzo 2009/6/11 Roy Stogner <roystgnr@...> > > On Thu, 11 Jun 2009, Jed Brown wrote: > > >> That's every quadrature point on reinit(elem, side), not on the > >> interior reinit(elem). The inverse map gets used on sides to > >> transform a quadrature rule on a d1 dimensional side element into > >> coordinates on the ddimensional master element. That may get > >> expensive for DG/jump calculations where every internal side is being > >> integrated on, but I'd be quite surprised if it was a major expense > >> for a CG assembly where the only side terms are on the domain > >> boundary. > > > > Run ex4 and look at the profiling output. An example run is attached. > > This shows 1 second total spent in element setup with almost half of > > that in inverse_map. It's remarkably expensive, and called multiple > > times (not an even multiple) per boundary face. That mesh has 6*32^2 = > > 6144 boundary faces, inverse_map is called more than 4 times this much > > (in one assembly). > > It's called once per boundary quadrature point (note that the > vectorize inverse_map() just calls the onepoint inverse_map() in a > loop)  that's 9 times per boundary face by default in ex4, I think, > which seems to square with your observations of ~4.5 local calls per > global boundary face when running on 2 processors. > > > It still only amounts to 10% of assembly time, so this isn't an > > issue anywhere near the scale Tim is running into. > > No. Tim's also running some larger scale problems, where any > inefficiency on the boundary will scale up more slowly than the rest > of the assembly. > > > Note that inverse_map could easily be a major bottleneck for CG in > > complex geometry, say bone structure analysis. > > Possibly. But it's been years since Ben decided that using > inverse_map for boundary quadrature was a good way to optimize for > programmer time at the expense of CPU time; IIRC Lorenzo just recently > became the first person to really disagree. > > > In any case, I doubt this has anything to do with ghosted vectors. > > No. >  > Roy > > >  > Crystal Reports  New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royaltyfree distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel > 