Adds PROCESSORS property to tests based on number of ranks and threads - #749
Adds PROCESSORS property to tests based on number of ranks and threads#749kennyweiss wants to merge 3 commits into
Conversation
…nd OpenMP threads This improves ctest's ability to schedule the tests. If NUM_MPI_TASKS or NUM_OMP_THREADS is not supplied, they are counted as 1.
white238
left a comment
There was a problem hiding this comment.
Thanks @kennyweiss ! Did you notice a speed up after this?
|
FYI: We have been using the and downloading and viewing the plots under the section "System RAM and Load Fracs Test Plot". |
|
@kennyweiss @white238 I tried adding PROCESSORS property on our tests in radar ( about 45 tests, mostly small, some multirank ), and it sped things up quite a bit for me. I tried running with 'ctest --parallel 112' on one of our nodes with 112 cores. I'm adding the property myself after blt creates the test but maybe we can look at the behavior later. These tests aren't multi-threaded however. One initial hiccup I had was I didn't make sure the srun jobs were launched with '--exclusive' so they were oversubscribed CPUs. (I was running ctest in an salloc). After I added: to my cmake host config everything worked well. I'll see if I can test your branch here. |
This PR add the
PROCESSORSproperty to tests in theblt_add_testmacro to give CTest more context in scheduling its tests.The number of processors is based on the number of mpi ranks -- provided through
NUM_MPI_TASKS-- and the number of OpenMP threads -- provided throughNUM_OMP_THREADS.We also throw a FATAL_ERROR if the number of threads is not an integer or is less than 1.
Update:
PROCESSORSproperty to tests appears to slow the testing down somewhat (~3% for the Axom tests).