Skip to content

Support

On this Page

  • What to check before you get in touch
  • How to reach the eResearch Support team, and what each channel is best for
  • What to include so we can help on the first reply
  • Requests that have their own form
  • Best practices for providing an example test dataset

Before You Contact Us

Three quick checks answer most questions, and none of them take long:

  • Is it already answered? The Frequently Asked Questions cover the problems we are asked about most often, including Why Is My Job Not Starting? and Why Did My Job Fail?.
  • Is the cluster busy rather than broken? A job sitting in PENDING is usually waiting for resources, not stuck. Cluster Traffic shows what is currently in use.
  • Is it your job or the cluster? If the same job worked yesterday and fails today, say so — that is one of the most useful things you can tell us.

How to Reach Us

Where to send what, and what comes back
Channel Best for You get
rtis.support@otago.ac.nz Anything at all, and always for continuing a conversation already under way A reply by email
Research Computing Teams channel Quick questions, and answers from other cluster users as well as from us A conversation

Email the eResearch Support team at rtis.support@otago.ac.nz. Most of us are not scientific or domain experts in your field, so the more you can tell us about what you were trying to do, the faster we can be useful.

Support graphic

What to Include

Whichever way you get in touch, these are what let us start work rather than start with questions:

  • The job ID, for anything involving a job. That alone tells us the node, the partition, the resources it asked for and how it ended.
  • The exact error message, copied as text rather than a screenshot. Screenshots are genuinely useful for graphical applications, but text output that we can search and paste back is far easier to work with.
  • The commands or job script you ran, and how you submitted them.
  • What you expected to happen, and what happened instead.
  • Whether it has ever worked — first attempt, used to work, or intermittent.
  • An example test dataset, if the problem needs data to reproduce. See best practices below.

Diagnostics to Paste In

Running these and pasting the output covers most of the list above in one go.

Terminal

# For a job problem — replace <jobid> with the job you are asking about
sacct -j <jobid> -o JobID,JobName,Partition,State,ExitCode,Elapsed,ReqMem,MaxRSS,NodeList
seff <jobid>

# For a software or environment problem
hostname
module list
which <command>

You do not need to interpret the output — send it as it comes. If you would like to read it yourself, Job Efficiency explains what seff and sacct are telling you.

Requests With Their Own Form

Some requests go through a form rather than an email, so that they reach the right people with the right details:

Request an Account Request Storage Request Globus Access

Best Practices for Providing an Example Test Dataset

When a problem needs data to reproduce, a small example saves everyone time:

  • Keep it small. Use the smallest dataset that still reproduces the issue — that makes it faster to diagnose for us, and often clearer for you.
  • Make it self-contained. Include the input files, the script and anything else needed to run it, so we are not chasing missing pieces.
  • Use a standard format. A text file or a widely-supported binary format is easiest for us to open.
  • Leave out sensitive data. Remove anything confidential or personally identifying before sharing it, and tell us if the real data has properties the sample does not.

What's next?