You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not all scheduler plugins function the same or require/support the same inputs. Most of us are familiar with PBS and SLURM, which both require the num_machines to be defined, and so most of our protocols define this in the resources option. However, there are other schedulers, such as the LSF for example, that do not accept this input and one has to set tot_num_mpiprocs. The question now is how to deal with this. In principle the generators could deal with this, but the question should they. Given the fact that they receive the code as input, they can get the type of the scheduler from the Computer for which that code is configured. In principle then, they could react on this, for example set num_machines for PBS and SLURM and tot_num_mpiprocs. The problem, however, is that it is not only impractical having to add this logic in all generators, it is also never going to be complete. Since new schedulers can be added through plugins, the protocols can never be complete for all potential schedulers out there.
The only way to generalize this is if it were possible to find the set of parameters that would cover all schedulers at a minimum and then add methods to the classes that define which parameters can and have to be set. Clients can then introspect this and act accordingly. Still I doubt whether it is feasible to nail down this set of parameters that should work for (almost) all schedulers. Other ideas?
The text was updated successfully, but these errors were encountered:
Not all scheduler plugins function the same or require/support the same inputs. Most of us are familiar with PBS and SLURM, which both require the
num_machines
to be defined, and so most of our protocols define this in theresources
option. However, there are other schedulers, such as the LSF for example, that do not accept this input and one has to settot_num_mpiprocs
. The question now is how to deal with this. In principle the generators could deal with this, but the question should they. Given the fact that they receive thecode
as input, they can get the type of the scheduler from theComputer
for which that code is configured. In principle then, they could react on this, for example setnum_machines
for PBS and SLURM andtot_num_mpiprocs
. The problem, however, is that it is not only impractical having to add this logic in all generators, it is also never going to be complete. Since new schedulers can be added through plugins, the protocols can never be complete for all potential schedulers out there.The only way to generalize this is if it were possible to find the set of parameters that would cover all schedulers at a minimum and then add methods to the classes that define which parameters can and have to be set. Clients can then introspect this and act accordingly. Still I doubt whether it is feasible to nail down this set of parameters that should work for (almost) all schedulers. Other ideas?
The text was updated successfully, but these errors were encountered: