roystgnr
commented
9 years ago That looks pretty devastating. Let me know if you need help bisecting.
Closed jwpeterson closed 9 years ago
roystgnr
commented
9 years ago That looks pretty devastating. Let me know if you need help bisecting.
jwpeterson
commented
9 years ago Bisection confirmed that the slowdown occurs due to libmesh/libmesh@3720bea, which is the commit where the improved second derivatives were merged. MOOSE is still "fast" on the commit right before that.
The thing is, most of the tests above should not actually need second derivatives to be computed (i.e. they involve only FIRST, LAGRANGE or CONSTANT, MONOMIAL finite elements on affine grids, so I'd like to find out where and why we're actually calling map_d2phi in MOOSE!
friedmud
commented
9 years ago I've tried to stomp out the second derivative computation before... but it keeps coming back. I'm interested to know what's causing it... On Thu, Apr 23, 2015 at 4:18 PM John W. Peterson notifications@github.com wrote:
Bisection confirmed that the slowdown occurs due to libMesh/libmesh@ 3720bea https://github.com/libMesh/libmesh/commit/3720bea, which is the commit where the improved second derivatives were merged. MOOSE is still "fast" on the commit right before that.
The thing is, most of the tests above should not actually need second derivatives to be computed (i.e. they involve only FIRST, LAGRANGE or CONSTANT, MONOMIAL finite elements on affine grids, so I'd like to find out where and why we're actually calling map_d2phi in MOOSE!
— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/4980#issuecomment-95707444.
permcody
commented
9 years ago air quotes """fast"""
permcody
commented
9 years ago Why are you always computing second derivates? Just go!
We need an RunException test where we create a first order problem and ask libMesh for second derivates. If that doesn't error out, we'll know we screwed something up.
jwpeterson
commented
9 years ago Doesn't seem like MOOSE is computing second derivatives too much... rather I slowed down compute_affine_map() "just a little bit", but "just a little bit" is not acceptable for a function called millions of times...
For this test case:
cd $MOOSE_DIR/test/tests/ics/constant_ic
../../../moose_test-opt -i subdomain_constant_ic_test.i -r 5Before second derivatives were computed correctly:
-----------------------------------------------------------------------------------------------------------------
| Event nCalls Total Time Avg Time Total Time Avg Time % of Active Time |
| w/o Sub w/o Sub With Sub With Sub w/o S With S |
|-----------------------------------------------------------------------------------------------------------------|
| |
| |
| FEMap |
| compute_affine_map() 19382274 6.6113 0.000000 6.6113 0.000000 11.34 11.34 |After second derivatives were computed correctly:
-----------------------------------------------------------------------------------------------------------------
| libMesh Performance: Alive time=106.535, Active time=101 |
-----------------------------------------------------------------------------------------------------------------
| Event nCalls Total Time Avg Time Total Time Avg Time % of Active Time |
| w/o Sub w/o Sub With Sub With Sub w/o S With S |
|-----------------------------------------------------------------------------------------------------------------|
| |
| |
| FEMap |
| compute_affine_map() 19349506 47.7421 0.000002 47.7421 0.000002 47.27 47.27 |(the slightly different numbers are due to using different versions of PETSc in two separate MOOSE builds, but you get the idea...)
Anyway, I think I can fix this fairly easily by doing a better job of skipping the extra computations for affine elements (as @roystgnr originally suggested!).
permcody
commented
9 years ago "Anyway, I think I can fix this fairly easily by not doing a better job of skipping the extra computations for affine elements"
Don't think I didn't cat that extra not in there before you edited the message...
So the parameter should be something like not_skip_extra_computations? :smile:
oh! and make sure you default it to false for maximum negatives!
jwpeterson
commented
9 years ago On Apr 23, 2015, at 5:08 PM, Cody Permann notifications@github.com wrote:
"Anyway, I think I can fix this fairly easily by not doing a better job of skipping the extra computations for affine elements"
Don't think I didn't cat that extra not in there before you edited the message... So the parameter should be something like not_skip_extra_computations?
oh! and make sure you default it to false for maximum negatives!
Hahaha. Only if you add it to the "requirements" document.
jwpeterson
commented
9 years ago fixed in b54d009
@jasondhales reported this, and it seems to be real, based on
./run_tests -s -t. Here are some timing numbers from my workstation both after (first column) and before (second column) the latest libmesh update:The first column is slower pretty much across the board. Not sure what is causing it yet, need to bisect on the libmesh side...