BIRCH on HPC systems
From Bioinformatics.Org Wiki
[return to Release To Do List]
Rationale: HPC systems are generally pretty opaque about what is on the system and how to use tools. Nowhere is the user-oriented advantages of BIRCH needed more than on multiuser HPC systems.
While BIRCH has evolved from day 1 as a multiuser resource, there are certainly going to be challenges on major platforms that will need to be addressed. This page will be the place for making BIRCH the best solution for a user accessible HPC system.
The test platform will be the Digital Alliance of Canada.
Important DCA links
Contents |
About DCA
The nibi.alliancecan.ca runs AlmaLinux 9.6, which is a free distro of RedHat Linux.
Getting BIRCH to run on DAC
Unique aspects of the DAC system
- Many software programs and packages don't simply run with a default. Programs are often wrapped in modules, and you have to choose which version of the software to run. This is done using
module load module_name
module load only applies to the shell in which it was launched, so if you want a personal default, the user has to run module load in their .profile, .bashrc other file at login.
- GenBank files do not need to be backed up, but do require fast reads by BLAST and FASTA. Ideally, this would be found in the scratch space. However, scratch files expire monthly. It may be possible to copy files or otherwise change modification dates once per month to avoid deletion.
- [Scratch purging policy https://docs.alliancecan.ca/wiki/Scratch_purging_policy]
- DAC hosts don't have a mail server. Instead, you need to use the mail notification that is part of SLURM jobs. When a SLURM job is finished, (see [Running Jobs https://docs.alliancecan.ca/wiki/Running_jobs#Use_sbatch_to_submit_jobs]), you need to add lines to your SLURM script to send the output to an email address when completed.
Example of lines to add to a SLURM job:
#SBATCH --mail-user=your.email@example.com #SBATCH --mail-type=ALL
The Slurm documentation explains the possible values for the `--mail-type` option: https://slurm.schedmd.com/sbatch.html#OPT_mail-type
BIRCH on Grex
- Grex admins have installed BIRCH on Grex (ood.hpc.umanitoba.ca) in /home/software/alma8/sb/opt/base/birch/4.0. This is also the value of the $BIRCH environment variable. BIRCH assumes a stable location, which is especially important for updates, so that locations of files don't change from one update to another. Adding a symbolic link called birch that points to the 4.0 directory might not fully solve this problem.
- The BIRCH app on ood.hpc.umanitoba.ca - This is a bit different model of usage than what is conceived of in BIRCH. Grex creates unique desktops around individual GUI apps. For example, Matlab, Mathematica etc. each have their own launcher from the web site, that launches a desktop with the application already open. So, the BIRCH button on the web site launches a desktop with the BIRCH BioLegato application already on the screen. The desktop has a pretty minimal offering of applications (eg. Xterm, LibreOffice) but many more are available from the command line if you know the command to type.
- By default, running newuser.py appears to be bypassed on Grex. However, you can run newuser from the command line. Initially, we do see the important environment variables (eg. $BIRCH) in a session. However, nothing is written to .profile or .bashrc etc. so it is not clear whether all things normally set up by the shell are getting done. Running newuser creates the dotfiles and adds the calls to the BIRCH setup scripts.
- Local customization - BIRCH expects a certain amount of localization by the BIRCH administrator. All localizations are done in $BIRCH/local, which persists through updates. Locally-installed applications can be installed in $BIRCH/local/script or $BIRCH/bin-xxx-xxx. Local settings are made in $BIRCH/local/admin. On Grex, the sysadmins are the only ones with write privileges for BIRCH. As well, the BIRCH administrator has to have write permissions for all of BIRCH, which gets deleted at the beginning of an update, with the exception of $BIRCH/local. I could potentially take on the responsibility of local customization, but that would need to be a shared collaboration with sysadmins.
- Web browser - Many programs in BIRCH produce HTML output that needs a web browser to read. The only browser available is NetSurf, which is still a bit of a work in progress. I agree with having a lightweight browser, but perhaps we need something a bit more mature. Issues with NetSurf:
- Won't display dropdown menus within a web page. Hovering over a dropdown menu gives the message "Warning: form cannot be submitted."
- No single-click way to open bookmarks
- The current DCA web site employs Anubis to prevent web bots from degrading performance of the web server. Unfortunately, the test of whether a user is human gets stuck at the "Loading..." message, and never ends up loading some pages.
- Terminal apps - only Xterm and "Simple terminal" are available. Incredibly, neither of these seems to support a way for selecting text to copy and paste. There are endless cases where you want to copy something from a terminal window, so I see this as a deal-breaker in and of itself. (Could this be an OOD issue, rather than a bug in Xterm?)
- ssh - Univ. of Manitoba CCL system unreachable - ssh ccl.cc.umanitoba.ca doesn't work from Grex. Neither does something like ssh userid 10.0.29.217 work, which gives a "no route to host" message. There does not seem to be any way to ssh to the U of M. system. The problem is likely due to the fact that Grex is not on the campus VPN.
Java
in local.profile.source
module load java
To load the default java version each time a shell is launched. I tried putting this line in local.profile.login.source, but it appeared to have no effect.
