#1150: Simfactory: it doesn't honor --procs when running testsuites -------------------------+-------------------------------------------------- Reporter: bmundim | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by bmundim):
People rarely want to specify the number of MPI processes. They typically
want to specify the number of >cores that they request from the queueing system, since this is what they pay for.
Wouldn't the be more natural that they submit their jobs through simfactory with a --cores option?
Given that the number of OpenMP threads is also fixed (either at one, or
at a small integer number >depending on the system hardware), then actual number of MPI processes then needs to be calculated >automatically. This is guaranteed to always lead to a "sensible" answer.
I agree. Most of the time users won't care for the number of MPI processes and or number of threads. That's what the machine database in simfactory is there for, and, as far as I understood, you wouldn't need to specify the number of threads per process you want, only the total number of cores or nodes (another interesting option would be --nodes or --num-nodes). However when we want to experiment with other configurations then the options become unintuitive. Also when I suggested --tasks or --mpi-tasks or --num-mpitasks I was referring tasks per node. Again that would be important only if the user wants to experiment (or to run testsuites).
The converse, e.g. specifying MPI processes and threads, can easily lead
to underused nodes.
That's correct if we are specifying the total number of MPI processes. That wouldn't be a problem if we specify the number of MPI processes per node in the same fashion we do specify the number of threads per MPI process.
Specifying cores and MPI processes can easily lead to strange (non-
optimal) numbers of OpenMP threads.
I agree. We either specify one or the other. Not both at the same time.
Under- and over-subscribing should work fine in Simfactory, apart from
particular submit scripts that >may not be able to handle this.
Ok, so it is only a matter of making the option names more intuitive for the work they are supposed to do.