Research IT hosted services
Please see our Cluter Usage documentation for our primary Cluster usage documentation.
We maintain documentation specific to some of the clusters and other systems we host here.
TCIN
Research IT host some systems for the Trinity College Institute of Neuroscience (TCIN).
Getting an account
First of all, make sure you have applied for your Research IT account: apply here.
MRI/EEG Booking System
In order to gain access to the MRI/EEG booking system:
Login to the TCIN Booking System with your Research IT account:
https://tcin-bookingsystem.tchpc.tcd.ie/Web/
Please note the TCIN Booking System is currently only available from certain parts of the College network, the TCIN desktop network and the College VPN.
Then send an email to Sojo Joseph, the MRI Radiographer, requesting access rights to make bookings.
Request access to the MRI Archives
In order to gain access to the MRI Archived data please send an email to rit-support@tcd.ie with the following details:
- Your Research IT username (see above for applying if you don't have one).
- The name and email address of the PI in who's group you work.
- A short description of the project you intend to undertake and its expected duration.
-
Please indicate which scanner data you require access to. If you do not know which one please ask the TCIN radiographer before making the request.
- Philips 3T
- Bruker 7T
- Simens DICOM (the default)
- Simens RAW
Access the MRI Archives
To transfer files from the MRI Archive please use the SSH protocol, (you will need an SSH file transfer client such as WinSCP), from the host neuro.tchpc.tcd.ie.
Please see our file transfer instructions for more details on how to do so.
| Scanner | Mount point on neuro.tchpc.tcd.ie |
|---|---|
| Philips 3T | /mnt/tcin-philips/philips/ |
| Bruker 7T | /mnt/tcin-bruker/bruker/ |
| Simens DICOM | /mnt/siemens-dicom/ |
| Simens RAW | /mnt/siemens-raw/ |
The neuro.tchpc.tcd.ie host is only accessible from the College network, not the internet.
TCIN HPC Cluster
Documentation on the Neuro HPC Cluster that TCIN have access to can be found here.
Tinney
Documentation on the Tinney cluster can be found here.
Plant Eco Model Storage Server for Botany Climate Group
To get access to the Plant Eco Model Storage Server you will require a Research IT account. Apply for an account with Research IT if you don't have one. We will confirm your access rights with the local contact when assigning your account permissions.
Please see our general instructions for how to transfer files.
Host name(s) to login to:
hprc-guest-114-232.tchpc.tcd.ieplant-eco-model.tchpc.tcd.iepem.tchpc.tcd.ie
(plant-eco-model and pem are DNS pointers to hprc-guest-114-232, all three host names will take you to the same server).
Astro Servers
astro01 is a 64 core, 128G of RAM, server hosted by Research IT for the Astrophysics group in the School of Physics (local contact: Prof. Luca Matra). This server was co-funded by the School of Physics and by the IRC through grant award IRCLA/2022/3788.
astro0i2 is a 128 core, 512G of RAM, server hosted by Research IT for the Astrophysics group in the School of Physics (local contact: Prof. Luca Matra).
Access
To get access to the Astro servers you will require a Research IT account. Apply for an account with Research IT if you don't have one. We will confirm your access rights with the local contact when assigning your account permissions.
Logging in with SSH
The endpoint's to connect to are:
-
astro01.tchpc.tcd.ie -
astro02.tchpc.tcd.ie
Please see our logging in instructions for more.
Logging in with VNC
(Will only work from the College network including the VPN).
Prerequisite: login to astro01 via SSH and run the vncpasswd command to set a VNC password if you have not set one. This step only needs to be done once but VNC won't work without it. Your VNC password will be separate from your Research IT login password.
Prerequisite: a dedicated tcp port number on astro01 is required for each user who wishes to use VNC. In the instructions below tcp port 5902 is used as the tcp port to run on on astro01.
If someone is already using tcp port 5902 on astro1 there will be a port conflict. (The command netstat -l | grep localhost:59 | grep -v tcp6 | awk '{print $4}' will display what ports in that range are being used on astro01).
Pick a number in the 59xx range, (that is an un privileged range), and replace 5902 below with it.
(1) From your desktop/laptop SSH port forward remote port 5902 to local port 5901.
E.g. from a Linux or MacOS clients open a terminal use the following command and replace username with your user name.
ssh -L 5902:localhost:5901 username@astro01.tchpc.tcd.ie
From a Windows client:
- Make sure VNC and Putty are installed.
- Enter
astro01.tchpc.tcd.iefor your session on port 22 - Click on Connections - SSH - Tunnels
- In the box labeled “Source Port”, type 5902
- In the destination box, type:
localhost:5901 - Source and further instructions. (Remember to update the hostnames etc if referencing that source).
(2) From an SSH session on astro01 start a VNC session with the command: vncserver -localhost.
Note: Check the VNC server is running with vncserver -list and if it is not running and you are using a conda environment or similar, deactivate the conda environment with conda deactivate.
(3) From your desktop/laptop point your VNC client/viewer to localhost:5902
E.g. for linux: vncviewer localhost:5902
From MacOS go to the Finder application and press the cmd and k buttons simultaneously. Enter vnc://localhost:5902 as the Server Address and click Connect.
Enter your VNC password and click Connect. Source and more information, (ensure to update the hostnames etc if using that page).
Note: if you get an error like: "The software on the remote computer appears to be incompatible with this version of Screen Sharing" when using MacOS you can use the modified command vncserver -localhost -SecurityTypes=None but note that means
you will not be prompted for a vnc password and it may be possible for another user on astro01 to connect to your vnc session. This is not recommended.
(4) To finish your VNC session kill it with: vncserver -kill :1 - assuming :1 is the session number, use vncserver -list to check.
Error: "XDG_CURRENT_DESKTOP=GNOME environment variable"
If you receive an error like the following:
Could not make bus activated clients aware of XDG_CURRENT_DESKTOP=GNOME environment variable: Could not connect: Connection refused
It may be because a conda or another tool that is modifying your environment is preventing VNC from launching. Please try to run VNC after running the command conda deactivate (assuming you are using conda) and see if VNC will then work for you.
Resetting your VNC password
If you lost your VNC password you can reset it with the following steps. This applies only to your VNC password on the system you have set it on and not on any other systems or passwords.
-
Delete the existing VNC password:
rm ~/.vnc/passwd(Note do not do this unless you want to reset your password) -
Run the
vncpasswdcommand again to set a new password.
File systems & quotas
/homeis nfs shared between astro01 and asto02 so they both see the same/homefile system./homeis for users home directories. A per user 500GB file system quota is applied to/home. If a larger quota is required please talk to the local contact in the Astrophysics group to liaise with Research IT./homeis backed up to tape. The backup schedule is a full backup every quarter and weekly incremental backups. There is a limit to the amount of data that can be backed up so backup usage of astro01 will be monitored and may have to be changed if it is taking too much backup space.- Both of astro01 and astro02 have a local
/scratchdirectory which is a ~1.8TB RAID0 volume stripped across two SSD's. That should make it a fast file system but/scratchhas no data redundancy, if one of the disks fails all data will be lost. Do not store data here that you cannot afford to loose. The/scratchon both astro01 and astro02 is separate, they are not shared file systems. Data in/scratchwill never be backed up./scratchis a shared file system, so users can modify and delete files owned by others. No file system quotas are applied to/scratch.
Checking /home quota usage
Use the qrep tool to see each users quota and usage in /home on astro01.
Jupyter Notebooks
Installation
(Should only be needed once)
> python3 -m pip install --user --upgrade pip
> python3 -m pip install --user jupyterlab
Note, this will also install ipython.
Access a Notebook from VNC
See the "Logging in with VNC" instructions above. Launch a terminal and run the command:
jupyter notebook
Access a Notebook via SSH
(1) Run jupyter on astro01:
jupyter notebook --ip 0.0.0.0 --port=8888
(2) Port forward, from your own computer run:
ssh -N -L 8080:astro01.tchpc.tcd.ie:8888 UESRNAME@astro01.tchpc.tcd.ie
Note: ensure to replace USERNAME with your username.
(3) Point your browser to http://127.0.0.1:8080/
Quit jupyter notebooks
- On astro01:
CTRL Cin the terminal running it - Close your browser
- Quit the port forwarding ssh session,
CTRL Cin that terminal or closing it should do.
Running jobs
The Slurm resource manager is installed on both astro01 and astro02. They each run slurm independelty, the queue is not shared between them and you cannot submit jobs from one of astro01 or astro02 to be run on the other server. Please use slurm as much as possible to run computationally intensive jobs as it will more equally share the machine and prevent resource contention, e.g. the same users using the same processors at the same time.
Please see our Slurm instructions for full information. Here are some quick pointers.
To run a python script called numbers.py on 4 cpu cores, (the -n flag):
srun -n 4 python numbers.py
To request 1 core for 6 hours, 15 minutes in an interactive allocation, (where you run the work yourself), use this command:
salloc -n 1 -t 06:15:00
Change the -n for number of processors and -t flags as needed.
Here is an example batch submission script that will request 12 cores for 1 day, 12 hours and 45 minutes. Again change the -n for number of processors and -t flags as needed. Batch jobs are ones where the scheduler runs the work for you.
#!/bin/bash
#SBATCH -n 12
#SBATCH -t 1-12:45:00
echo "Starting job at:"
date
echo "On machine:"
hostname -f
# [run your executable](#run-your-executable)
./exe
Assuming you have called the file run.sh you can submit it to the queue with this command:
sbatch run.sh
To check what is running in the queue you can use the squeue command.
Acknowledgements policy
As per our acknowledgements policy please use the following acknowledgement line:
All calculations were performed on the astro01 and astro02 system's maintained by the Trinity Centre for High Performance Computing (Research IT). This system is co-funded by the School of Physics and by the Irish Research Council grant award IRCLA/2022/3788.