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
