More flexible list mode

[David Dickinson]

The list mode can be quite useful but has some restrictions, such as requiring a uniform number of processors per job and for all processors to be used (i.e. nproc/njob integer and nproc - (nproc/njob) * njob == 0).

It should be possible to relax these restrictions and allow a variable number of processors to be used per job and for some processors to go unused. This would simply require sum(nproc_job) <= nproc.

One could imagine changing the list entry from <input_name_without_dot_in> to <input_name_without_dot_in> <nproc_to_use> . We would need to change init_jobs in mp to use a more general subcommunicator creation than the cartesian creation currently used. For example something like

iproc\_start = 0

do i = 1, njob

‌    if \(iproc >= iproc\_start .and. iproc < iproc\_start \+ nproc\_job\(i\)\) then

‌         colour = i

   end if

   iproc\_start = iproc\_start \+ nproc\_job\(i\)

end do

would give each processor a colour based on the job they will be responsible for.

This should work fine for the typical list mode use however init_jobs is also designed with trinity in mind where one may potentially want communication between the created sub-communicators (perhaps) which may benefit from the more structured cartesian communicator. One solution would be to simply provide an alternative init_jobs_flexible or similar which implements the new approach. It may even be possible to auto-detect if the passed list file contains processor counts or not and call the appropriate init_jobs routine automatically.

‌

A further enhancement would be to allow the user to request that a subset of the jobs are run at a time. This would likely require more refactoring in the main code unit.