All met-cluster users should migrate their applications to RACC. User accees to the met-cluster is now disabled.
The two main differences between RACC and met-cluster are that 1. on RACC you are automatically logged in on one of the login nodes which are load balanced and suitable for interactive computing (but not for background jobs), and 2. the difference in how batch jobs are submitted.
On the RACC, the default shell for all users is bash, and we encourage all users to use bash as their interactive shell. If you don’t have one already, you can create your ~/.bashrc, e.g. with the command:
cat /etc/skel/.bashrc >> ~/.bashrc cat /etc/skel/.bash_profile >> ~/.bash_profile
however, if you do not do it, bash will work fine anyway. Here we need both ~/.bashrc and ~/.bash_profile because bash confuses users by executing ~/.bashrc only for interactive non-login shells and ~/.bash_profile for login shells, and a standard workaround is to run ~/.bashrc from ~/.bash_profile, as in the files provided here, such that ~/.bashrc can be used for all cases.
met-cluster users might want to use ksh to run their existing scripts. If their user account was created before Jul 2018, most likely they already have Met ~/.kshrc. Legacy Met ~/.kshrc will continue to work on RACC, and it should not be removed because it might be still needed on met-cluster. New users will need the create their ~/.kshrc which contains a couple of lines needed to set up their ksh environment. This can be done with the command:
cat /etc/skel/.kshrc >> ~/.kshrc
Batch jobs in ksh won’t find the ‘module’ command without a little extra help. If you are submitting a slurm batch script that loads a software module, please add the line
in your job script before your ‘module load’ command.
Cronjobs can be scheduled on the dedicated node racc-cron.act.rdg.ac.uk. Beside the specific purpose it is a cluster node with the same software configuration. Unlike on met-cluster, user code can be run directly from crontab now, it does not have to be submitted as a batch job. From definition, batch jobs might need to wait for resources, which is not perfect if timely execution of a small task is expected. However the tasks submitted as cronjobs have to be sufficiently lightweight to not overload and monopolize the server and when required, cronjobs still can be used to submit batch jobs. A local cronjob tutorial can be found here: Cronjobs on the Academic Computing Cluster.