-
Notifications
You must be signed in to change notification settings - Fork 37
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
Mapping of scheduler jobs to project #3
Comments
This issue, or #146, would solve a problem raised by @ramanishsingh and @rsdefever at the @mosdef-hub all-hands meeting. They want to be able to put log files generated by PBS/SLURM into the corresponding job directory folder. Of course there isn't a 1-1 mapping between scheduler jobs and signac jobs, but we could probably find a way to do better than the current behavior. |
A related use is tracking scheduler job IDs to track down errors more easily. It might be a separate issue. My current solution involves: (1) using a custom template that emails me the status, so I get an email with a subject like:
(where Flow prints out this in this case
(2) saving (currently by copy-paste but I know I could dump the output to a file) what flow prints out when I submit jobs.
This is the only way I know to associate the submission ID (now the ID of the bundle) with the job.id. I look up the submission ID and find jobs in this list or find the job.id and go to its parent submission ID. A possible solution? |
Do schedulers return job ID? However (!), I found references to scripts that return the ID when submitting:
On Torque, I think the answer is yes from discussion below. |
Some notes from discussion with @csadorf and @bdice yesterday afternoon:
|
Original report by Carl Simon Adorf (Bitbucket: csadorf, GitHub: csadorf).
Problem
The FlowProject currently provides the
scheduler_jobs()
and themap_scheduler_jobs()
method. These can be used to identify scheduler jobs that belong to the project within the current environment, but are still kind of awkward to use. For example, it should be simple to iterate through all scheduler-jobs associated with the current project, e.g. to change their status.Current Solution
This is the code currently required to do so:
The reason for this rather convoluted approach is to enforce the querying of the environment scheduler only once as opposed to multiple times, for example for each job.
Proposed Enhancement
I propose to protect the environment scheduler resource, using the following API:
The text was updated successfully, but these errors were encountered: