-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intrepid2: Disable test #13707
Intrepid2: Disable test #13707
Conversation
In line with previous changes to disable building some of these tests, disable one that is consistently failing to compile with AT2. I did some diagnosis on this, since it was apparently succeeding to build with the AT1 configuration/machine, and I didn't want to disable it if necessary. The load numbers on the AT2 machine show the CPU spiking to over 100%, but only for 1-2 minutes. When I checked one of the AT1 machines, I saw the same spike, but only to about 60%. This makes sense, since the parallelism for these machines is higher, given that they have more CPUs. I think the trade-off of disabling this test vs. slowing down the build of all other tests is justified (though unfortunate). We shall see what this does to the load numbers. Some sort of randomized compile order could also help avoid this type of issue happening repeatedly in the future. Signed-off-by: Samuel E. Browne <sebrown@sandia.gov>
Status Flag 'Pre-Test Inspection' - Auto Inspected - Inspection is Not Necessary for this Pull Request. |
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects: Pull Request Auto Testing STARTING (click to expand)Build InformationTest Name: PR_gcc-openmpi-openmp
Jenkins Parameters
Build InformationTest Name: PR_gcc
Jenkins Parameters
Build InformationTest Name: PR_gcc-openmpi_debug
Jenkins Parameters
Build InformationTest Name: PR_clang
Jenkins Parameters
Build InformationTest Name: PR_cuda
Jenkins Parameters
Build InformationTest Name: PR_intel
Jenkins Parameters
Build InformationTest Name: PR_cuda-uvm
Jenkins Parameters
Using Repos:
Pull Request Author: sebrowne |
Status Flag 'Pull Request AutoTester' - Jenkins Testing: all Jobs PASSED Pull Request Auto Testing has PASSED (click to expand)Build InformationTest Name: PR_gcc-openmpi-openmp
Jenkins Parameters
Build InformationTest Name: PR_gcc
Jenkins Parameters
Build InformationTest Name: PR_gcc-openmpi_debug
Jenkins Parameters
Build InformationTest Name: PR_clang
Jenkins Parameters
Build InformationTest Name: PR_cuda
Jenkins Parameters
Build InformationTest Name: PR_intel
Jenkins Parameters
Build InformationTest Name: PR_cuda-uvm
Jenkins Parameters
|
Status Flag 'Pre-Merge Inspection' - - This Pull Request Requires Inspection... The code must be inspected by a member of the Team before Testing/Merging |
All Jobs Finished; status = PASSED, However Inspection must be performed before merge can occur... |
Status Flag 'Pre-Merge Inspection' - - This Pull Request Requires Inspection... The code must be inspected by a member of the Team before Testing/Merging |
All Jobs Finished; status = PASSED, However Inspection must be performed before merge can occur... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm. Thanks for the plot on CPU resources.
Status Flag 'Pre-Merge Inspection' - SUCCESS: The last commit to this Pull Request has been INSPECTED AND APPROVED by [ mperego ]! |
Status Flag 'Pull Request AutoTester' - Pull Request will be Automerged |
Merge on Pull Request# 13707: IS A SUCCESS - Pull Request successfully merged |
@trilinos/intrepid2
Motivation
Repeated compile failures building
Intrepid2_unit-test_Discretization_Basis_HGRAD_TRI_Cn_FEM_test_02_CUDA_DFAD_DFAD
(example). With the approach of the AT2 CUDA build being transitioned to production, we need the line clean.Testing
Same paradigm as used elsewhere.
I did some diagnosis on this, since it was apparently succeeding to build with the AT1 configuration/machine, and I didn't want to disable it if at all possible. The load numbers on the AT2 machine show the CPU spiking to over 100%, but only for 1-2 minutes. When I checked one of the AT1 machines, I saw the same spike, but only to about 60%. This makes sense, since the parallelism for these machines is higher, given that they have more CPUs. To me, this indicates that something (small number) are using a lot of CPU resources, as opposed to the entire build hitting the machine too hard. I think the trade-off of disabling this test vs. slowing down the build of all other tests is justified (though unfortunate). We shall see what this does to the load numbers. Some sort of randomized compile order could also help avoid this type of issue happening repeatedly in the future.
Memory usage looked fine on both machines.
AT1:
AT2: