On Tue, Mar 30, 2021 at 12:25 AM Barry Smith <[email protected]> wrote:

# FAILED snes_tutorials-ex12_quad_hpddm_reuse_threshold snes_tutorials-ex12_p4est_nc_singular_2d_hpddm snes_tutorials-ex56_hpddm snes_tutorials-ex12_quad_hpddm_reuse_threshold_baij sys_tests-ex53_2 snes_tutorials-ex12_quad_hpddm_reuse_baij snes_tutorials-ex12_quad_hpddm_reuse snes_tutorials-ex12_p4est_singular_2d_hpddm snes_tutorials-ex12_tri_parmetis_hpddm snes_tutorials-ex12_quad_singular_hpddm sys_tests-ex26_1 sys_tests-ex26_2 snes_tutorials-ex12_tri_parmetis_hpddm_baij snes_tutorials-ex12_tri_hpddm_reuse_baij snes_tutorials-ex12_tri_hpddm_reus

Scott,

Any thoughts on how the test harness could tell the developer exactly how to reproduce a problematic cases in the debugger without them digging around in the code to check arguments etc.

So for example "Run: mpiexec -n N ./xxx args -start_in_debugger" to reproduce this problem? Then one could just cut and paste and be debugging away.

I always just EXTRA_ARGUMENTS="-start_in_debugger". However, if you really want to run standalone, V=1 will display the args I think Thanks, Matt

Thanks

Barry

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>