One thing I felt was always missing from cluster_utils is a command that starts a single job, without me having to write a complex config file. Something like a convenient wrapper around condor's .sub files.
I imagine such a command to have something like the following interface:
So everything that can be specified in the usual config files would also be exposed here, with a sensible sets of defaults. An advanced feature would be to allow the user to specify a set of commonly used options that are stored as profiles. A more complex feature would be to parametrize arguments on the command line, resulting in a grid search-like behavior.
Even better would be if it is not required to instrument the executable with cluster_utils calls. Maybe then there would be missing features, e.g. the state of the job can not be tracked, but it offers quick convenient interface to the cluster.
One thing I felt was always missing from cluster_utils is a command that starts a single job, without me having to write a complex config file. Something like a convenient wrapper around condor's
.sub
files.I imagine such a command to have something like the following interface:
So everything that can be specified in the usual config files would also be exposed here, with a sensible sets of defaults. An advanced feature would be to allow the user to specify a set of commonly used options that are stored as profiles. A more complex feature would be to parametrize arguments on the command line, resulting in a grid search-like behavior.
Even better would be if it is not required to instrument the executable with cluster_utils calls. Maybe then there would be missing features, e.g. the state of the job can not be tracked, but it offers quick convenient interface to the cluster.
By @mseitzer (imported from GitLab)