-
Notifications
You must be signed in to change notification settings - Fork 45
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
TRIBITS_ADD_ADVANCED_TEST(): Add postfix _MPI_<num_procs> to test names #37
Comments
Given my analysis below, it looks like we will only need to update the following repos and packages:
I can take care of Zoltan and VUQDemos. I can't fix SCALE or Exnihilo. I will have to ask those developers to do that. Also, I can't fix SEACAS because it is a SIERRA package. I will have to ask someone on that side to update the code. DETAILED NOTES: So, I have done an analysis on VERA (which includes Trilinos) and it seems there are several different places where people are setting custom properties on tests. I found these with:
This gives a total number of lines:
We are most concerned about setting test properties:
Now some of these are actually in TriBITS itself and some are in MOOSE (in libmesh TPLs). If you screen those out you get:
A bunch of these are zoltan setting RUN_SERIAL on TRIBITS_ADD_ADVANCED_TEST() tests. Well, TRIBITS_ADD_ADVANCED_TEST() now has the RUN_SERIAL argument so that should not be needed. However, non one should be using the RUN_SERIAL argument as it stops all parallel running of tests! Those will need to be updated but it is just a simple matter of adding the RUN_SERIAL argument. Excluding the Zoltan tests gives:
So that leaves just 61 instances to go through. There are bunch of these in VUQDemos where they are setting the PROCESSORS property to deal with the fact that Dakota uses a bunch of processes internally but not through mpirun. Those will need to be updated but they are easy to find. A few are actually in Dakota itself which does not use TriBITS. Excluding the VUQDemos and Dakota and we have:
Most of what is remaining is in SCALE:
Many of those may need to be updated. Another sizable chunk is in Exnihilo:
Many of those will need to be updated as well. There are also a few in Dakota/ itself which does not use TriBITS so I can exclude those as well What is left is not much:
That leaves just 7 lines of CMake code to look at outside of Zoltan, VUQDemos, SCALE and Exnihilo. So the VRIPSS Drekar driver is not used anymore and can likely be deleted. Same for the VRIPSS Peregrine driver. Then there is a strange kill_memcheck_processes test which is in the outer TrilinosDriver project that does not use TAAT(). Also, anything with MPI[1-9] was not added with TAAT() because it does not add the postfix yet. That leaves just:
Wow, just one test in SEACAS. But since Exodus is a SIERRA package, I can't fix this. Darn. So I will have to ask someone on the SIERRA side. The final list of repos/packages that may need to be updated to use the ADDED_TEST_NAME_OUT argument are:
There does not appear to be any other TriBITS repos or package that are explicitly setting test properties. |
The current implementation of
TRIBITS_ADD_ADVANCED_TEST()
never adds the postfix_MPI_<num_procs>
to test name in an MPI build. This is not consistent withTRIBITS_ADD_TEST()
which does add this postfix. It turns out that seeing the number of MPI processes right in the test name is a very useful bit of info when trying to assess a test suite. For example, if a test is using a lot of processes and is taking a long time to run, that is a very expensive test and needs to be trimmed down or relegated from theBASIC
category to theCONTINUOUS
orNIGHTLY
or evenWEEKLY
category.The number
<num_procs>
used for of_MPI_<num_procs>
would be the largest number of processes used by any of the individualTEST_<IDX>
blocks. For example, ifTEST_1
usesNUM_MPI_PROCS 5
andTEST_2
usesNUM_MPI_PROCS 7
, then the name postfix_MPI_7
would be used.The challenge with making this change is that technically this change will break backward compatibility if any CMake code was referring to the test name, for example to set extra test properties. However, the new argument
ADDED_TEST_NAME_OUT <testName>
can be used to address this (see #4).The text was updated successfully, but these errors were encountered: