Project

General

Profile

Bug #3084

gmx report-methods test unstable

Added by Mark Abraham about 1 month ago. Updated 4 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
analysis tools
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

This test is intermittently failing on agent "clang-7 no-hwloc tsan libcxx-7 openmp cmake-3.12.1 simd=avx2_256 host=bs_gpu01"

00:06:08.638 [ RUN      ] ReportMethodsTest.ToolEndToEndTest
00:06:08.638 
00:06:08.638 NOTE 1 [file /mnt/workspace/Matrix_PreSubmit_master@2/61af288e/gromacs/src/gromacs/tools/tests/Testing/Temporary/ReportMethodsTest_ToolEndToEndTest_lysozyme.mdp, line 1]:
00:06:08.638   /mnt/workspace/Matrix_PreSubmit_master@2/61af288e/gromacs/src/gromacs/tools/tests/Testing/Temporary/ReportMethodsTest_ToolEndToEndTest_lysozyme.mdp did not specify a value for the .mdp option "cutoff-scheme". As of GROMACS
00:06:08.638   2020, the Verlet scheme is the only cutoff scheme supported. This may
00:06:08.638   affect your simulation if you are using an old mdp file that assumes use
00:06:08.638   of the (removed) group cutoff scheme.
00:06:08.638 
00:06:08.638 
00:06:08.638 NOTE 2 [file /mnt/workspace/Matrix_PreSubmit_master@2/61af288e/gromacs/src/gromacs/tools/tests/Testing/Temporary/ReportMethodsTest_ToolEndToEndTest_lysozyme.mdp]:
00:06:08.638   For a correct single-point energy evaluation with nsteps = 0, use
00:06:08.638   continuation = yes to avoid constraining the input coordinates.
00:06:08.638 
00:06:08.638 Setting the LD random seed to 208945922
00:06:08.638 
00:06:08.638       Start 41: FileIOTests
00:06:08.693 41/49 Test #41: FileIOTests ......................   Passed    0.11 sec

My guess is that something with the new density fitting functionality was not anticipated and now doesn't work. Can you take a look Paul and Christian?


Related issues

Related to GROMACS - Task #2971: Rework TPR reading to allow reading of raw bytes from disk and communication of complete information at setup timeClosed

History

#1 Updated by Mark Abraham about 1 month ago

I'm going to disable this test for now

#2 Updated by Paul Bauer about 1 month ago

  • Target version changed from 2020-beta1 to 2020-beta2

changed target until we figure out what is going on

#3 Updated by Paul Bauer about 1 month ago

Have been building the same target on the node and ran the test manually, nothing comes up when running the test on its own, but it times out when running all the tests using ctest.
I think this is related to node load, as the individual tests can take quite long when run manual.

#4 Updated by Mark Abraham about 1 month ago

Paul Bauer wrote:

Have been building the same target on the node and ran the test manually, nothing comes up when running the test on its own, but it times out when running all the tests using ctest.
I think this is related to node load, as the individual tests can take quite long when run manual.

OK, but I have seen that particular test fail multiple times, and not e.g. any of the long-running MdrunTests, etc. in this test configuration. Why is this one particularly susceptible? How long does it take under favorable circumstances?

#5 Updated by Paul Bauer about 1 month ago

I checked the individual timing and saw that each test case can take more than 10 seconds for generating and reading in the TPR for some reason, so that might be the issue.

#6 Updated by Paul Bauer 7 days ago

  • Status changed from New to Resolved

this should be resolved now with cef36d09e64b3f5e3a0248722d8da8d7f1cc584d being submitted

#7 Updated by Mark Abraham 6 days ago

  • Related to Task #2971: Rework TPR reading to allow reading of raw bytes from disk and communication of complete information at setup time added

#8 Updated by Paul Bauer 4 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF