[ENH] Determine the strategies for cluster abstraction

[zhao-cy]

Discussed in #27

^{Originally posted by zhao-cy February 19, 2023}
Currently BABS is only compatible with SGE clusters; the next step is to make it compatible with Slurm, then probably LSF.

Based on what I've checked so far, there are several ways for cluster abstraction:

1. Simplest way: if/else. Probably suitable for a short function.

The next two ways require some summary first: summarize the behavior of different clusters (e.g., at least SGE and Slurm, if possible also LSF), define the consistent methods/function names/keywords (e.g., submission), then:

2. Dictionary-based: a dictionary (e.g., in a YAML file) to look up, with keys consistent across cluster systems.

• Currently part of BABS uses this way:
  • in YAML file babs/dict_cluster_systems.yaml, we define how SGE clusters would handle different cluster resources request;
  • then in babs/utils.py, in function generate_one_bashhead_resources() we can use dictionaries defined in the YAML file to generate cluster requests.

3. Class-based: build one class for each cluster system, with (some of) methods’ names consistent across cluster systems

• Potential advantages over YAML file of dictionary: can directly return a full command with inputs taken in, e.g., return ['scancel', '-Q', native_id]
• Examples using this way:
  • psi-j: each cluster system has a python script in this folder
  • Unicore: each cluster system has a python file BSS.py in a folder (e.g., this for slurm)
  • ReproMan: see this python script
  • gc3pie: Python files, e.g., this for SGE, this for Slurm
  • Nipype seems also adopts similar way