General overview¶
BgQmap¶
BgQmap is a tool aimed to ease the usage of a cluster.
BgQmap contains 5 different tools:
- run: execute commands with extended resources
- template: create a jobs map file
- submit: submit jobs from a map file
- reattach: reattach to a previous bgqmap execution
- info: explore the metadata of your jobs
Currently, only SLURM is supported as workload manager.
Tools¶
- bgqmap run
Execute a command with more resources maintaining your working environment
bgqmap run -m <memory> -c <cores> "<command>"
- bgqmap template
Create a jobs map file that works with bgqmap submit.
bgqmap template "<command with wildcards>" -f <jobs map file>
The file created uses the current loaded Easy Build modules and the current conda environment as jobs pre-commands [1] if not explicitly provided.
The job commands are all the combinations that result of the expansion of:
{{list,of,items}}: comma separated list of items {{file}}: all lines in file *, ?, [x-y]: wildcards in Python’s glob module Wildcards of the format
{{...}}are expanded in a first phase and glob wildcards are expanded later on.As additional feature, any of the above mentioned groups can be named
{{?<name>:...}}and replaced anywhere using{{?=<name>}}.Note
To name glob wildcards they should be solely in the group. E.g.
{{?myfiles:*}}- bgqmap submit
Execute all jobs from a jobs map file
bgqmap submit -m <memory> -c <cores> <jobs map file> --logs <logs folder> --max-running <#>
bgqmap submithas been implemented to submit a set of jobs to a cluster for execution and control them. It acts as a layer between the workload manager and the user preventing she/he from submitting a huge number of jobs at once (potentially blocking future users). The number of jobs that can be submitted to the workload manager is controlled by the –max-running flag.Warning
If
bgqmap submitis closed, jobs that have not been submitted to the workload manager will never be. Thus, it is recommended to run it inside a screen.In addition, in the folder indicated to store the logs with the –logs flag the user can find important information about each job execution as well as the logs from STDOUT and STDERR.
Another feature of this tool is the possibility to group your jobs with the –grouping option. This option uses the value passed as the number of commands that fit in each job. Thus, several commands can be executed as part of the same job, one after another. This option can be interesting for “small” jobs as they use the same allocation. If any of the commands fail, the associated job will fail.
Finally, any job command can include two values that are substituted before execution:
${{JOB}}: identifier of the job ${{LINE}}: identifier of the line the job command has in the input file Note
${{JOB}}is the same for all job commands within a group- bgqmap reattach
Once a
bgqmap submitexecution is closed, you can reconnect from its logs directorybgqmap reattach --logs <logs folder>
Note
If in the previous execution there were jobs that have not been submitted to the workload manager
bgqmap reattachwill start to submit them.- bgqmap info
bgqmap submitgenerates a file for each job with metadata information.bgqmap infois designed to explore them and retrieve the requested data. Information is stored in json format and the user can request any fields:bgqmap info --logs <logs folder> <field 1> <field 2>.<subfield 1> ...
In addition, the –status option can be used to filter the jobs by their status (completed|failed|other|pending|running|unsubmitted|all).
If you do not pass any field, then the return value is the input commands of the jobs.
Jobs map file¶
This file contains a list of the commands to be executed as well as commands to be executed before and after each job (e.g. loading Easy Build modules or conda environments). The format of the file is:
# command to be executed before any job
## parameters for all the jobs (e.g. cores=7, memory=16G)
job command
job command
# command to be executed after any job