So it looks like nearly all of the time for this problem is spent in System::project_vector() as you already guessed. The most expensive call being in "OldSolutionValue".
So how are we getting on this code path? The PenetrationAux kernels in MOOSE turn on various machinery for GeometricSearch which triggers extra ghosting. Specifically, this call is triggered via MOOSE's FEProblem::reinitBecauseOfGhostingOrNewGeomObjects() which is only taken when we are doing Geometric search for contact type problems. This is one of Derek's test so he might have additional information on exactly how he's engineered it but if you just open up the mesh file for that test you'll see that one 3d block is completely in contact (actually penetrating) with another large 3d block meaning we have a lot of ghosting to do. Cody On Mon, Oct 26, 2015 at 3:12 PM Cody Permann <codyperm...@gmail.com> wrote: > Fortunately we did our libMesh update before that merge so none of our > users are using it. We probably won't do another for several weeks. This > may or may not affect certain libMesh users though so I'll let you make > that decision. > > On Mon, Oct 26, 2015 at 3:05 PM Roy Stogner <royst...@ices.utexas.edu> > wrote: > >> >> On Mon, 26 Oct 2015, Cody Permann wrote: >> >> > I just pulled the latest libMesh head and saw a serious performance >> penalty that I narrowed down to 445b1c3 with John's help. We've had this >> test >> > for several years and it's been relatively stable. It's two overlapping >> structured 3D grids, one slightly embedded inside of the other. We are >> > testing for penetration, not really solving anything. >> > Input file here: >> > >> https://github.com/idaholab/moose/blob/devel/test/tests/geomsearch/3d_penetration_locator/3d_penetration_locator_test.i >> > >> > Time before 445b1c3: ~5.5 seconds >> > Time at 445b1c3 ~60-65 seconds >> > >> > Based on the output, I can tell you that the time is NOT being consumed >> by the solve. That "looks" unchanged. I assume that the extra time is >> > occurring during the mesh setup. I'll let you know more as I get more >> information. >> >> Damn, thanks for the heads up! I'll see if I can reproduce the >> problem. Do you want to revert for now? >> >> This is baffling - that PR should have only affected the performance >> of vector projections: i.e. post-solve AMR. Unless I'm >> misunderstanding that input file, the new code path shouldn't even be >> called at all! >> --- >> Roy > >
------------------------------------------------------------------------------
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
