Getting Help

1. How to ask for Help

The resources at RCIC are here to help the UCI research community. There are literally 1000’s of accounts on our resources, representing disciplines from every corner of UCI.

Because this is a research environment, we are asked quite often to add new hardware or software. We do our level best to balance stability with the "latest and greatest" software. But, bugs creep in and hardware goes sideways.

There are two major ways to ask for help on our resources

Ask the UCI Community

As part of the launch of HPC3, we are adding a Google Groups discussion list. If you subscribe to this list, you can ask questions of the greater UCI research community. There are many knowledgeable people at UCI, they can help. RCIC will also monitor and respond to posts in this discussion group. Conversations are archived so that you can search previous posts.

To subscribe, first login at using your UCI credentials (every UCI user ha a google account). Once logged in, follow the link Google Groups discussion, this should allow you to make a subscription to the group list.

if you are outside of UCI or part of UCI Health Sciences, you can join, too. Generate a support ticket (see below) with a request to join the Google Group.
Generate a support ticket

Send email to describing your problem. Sending email will automatically generate a "ticket" in our trouble tracking system. We try to respond by the next business day.

2. Support Tickets

If you use HPC3 long enough, you will need to submit a support ticket to us. How you submit your ticket and the information you include can greatly speed up resolution. The system is complex with many users, simple requests don’t need to be elaborate, but when something is broken, good descriptions and information really (really) can help us hone in on the root cause.

2.1. How to submit a support ticket

Please follow Good Support Ticket Practices outlined below:

  1. Before submitting a ticket, try your best to see if the problem is a simple one: file permissions, quota problems and the like. Many of these you can solve yourself after reading our guides.

  2. Provide relevant information:

    Essential Elements of Support Ticket
    • Which modules did you load

    • What exact commands you typed

    • What exact output you saw

    • What file path(s), input/output you used

    • Specific job number and a full path to your submission script

  3. Do not:

    • be vague. Statements like it’s slow, or my code doesn’t work give us nothing concrete to track down.

    • put in Red Herrings or other irrelevant statements

  4. Be reasonable and polite. We know when something goes wrong, it’s very stressful. It’s stressful for us, too. We often work after hours and weekends to keep outages to a minimum.

  5. Once your problem is resolved, acknowledge this so we can close the ticket

A pretty good perspective on How to Report Bugs Effectively illustrates some the reasons for the detail. High-end computing is a team sport!

Please remember that if we cannot reproduce your problem, we cannot fix it!

2.2. Login problems

When reporting login problems please include the following:

  1. Where are you trying to log in FROM (from campus? over the VPN?).

  2. What kind of computer and Operating System you’re connecting from? This is especially useful for connection-related problems.

  3. What software are you using to connect and which version?

  4. What exact commands you typed

  5. What exact error message you saw?

  6. What did you find when you searched Google with that error message?

2.3. Cluster Problems

When reporting errors related to batch system, quota, etc. the exact error message is important.

Please include this information:

  1. Your UCINETID (not everyone uses '')

  2. Working directory (output of pwd command, if it’s not in your prompt)

  3. Full path of files that you reference

  4. Machine or node where you see the issue

  5. Modules loaded (output of module list)

  6. Exact Command you used or if it was caused by a script, the full path to the script. Copy the text of the command. Do not send us a screenshot of the commands unless you’re using a graphics program and the problem is more succinctly described with a screenshot

    Break long commands into readable length with the use of the continuation character \. Instead of one continuous line which will cause line breaks randomly use implicit line breaks:

    This format is difficult to read:

    $ -i wetdry_cr/beta_diveuclidean/beta_div_euclideancoords.txt -m wetdry_cr/mapping_files/merged_mapping_data.txt -b 'Elevation' -o wetdry_cr/2dplots/elevation

    This format is much easier to read and to understand:

    $ \
         -i wetdry_cr/beta_diveuclidean/beta_div_euclideancoords.txt \
         -m wetdry_cr/mapping_files/merged_mapping_data.txt \
         -b 'Elevation' \
         -o wetdry_cr/2dplots/elevation
  7. The exact output and exact error that the command caused, including the full path to the output/error files if they were generated. The scheduler will drop error files in your $HOME or in a directory from which you submitted the job. Do not send us a screenshot. You might also examine the contents of output/error files before you call for help.

  8. If the error was more than a few lines, copy/paste them into pastebin (please don’t include sensitive information in public 'pastes')

3. Request New software

RCIC builds and maintains an extensive collection of domain-specific software. Some software is really very straightforward to build and deploy to the cluster, other software can be extremely challenging to get built and installed.

Given realities of time, we have to prioritize software that affects more than a single researcher or group. We certainly are not here to install software that you might use or just want to play with or evaluate. Even with those constraints, we are not shy about taking on complicated, time-consuming installs with many dependencies. Part of our value add to UCI is to handle as much of this as possible. We strive to say "yes" to software requests, but sometimes do have to say "no."

3.1. Install it yourself

We encourage users to see if they can build/install the application in their home area/parallel file system area, first. When you attempt this yourself, you need to be aware that this is CentOS-based system. If you run across instructions that say Ubuntu or apt get or similar, those are for a different Linux-based OS and won’t work on HPC3.

Sometimes people will request sudo access. The answer is always: sudo access is not allowed.

The most common request is for some specific Python, R, or Perl package. These very often can be installed on a per-user basis in user directories. Please see the following guides that explain how to install common packages in user area on HPC3:

R packages

Python packages with pip

Bulding Conda local environments

Perl CPAN modules

3.2. Submit a Ticket

You might not be able to install/compile the software yourself without some additional system-installed software and that’s a good reason to ask us. There are many other good reasons to ask us to build/install new software, too. First, do as much as you can reasonably do yourself. In the end, it’s a partnership to get new software added to HPC3. We need good information from you and a willingness to validate the software.

If you want to request new software (or updated versions of software that are already on HPC3) please send email request to with the following information:

Elements of a Software Request
  1. Software name and version

  2. URL for download/install instructions

  3. If applicable, any special configuration options/capabilities that should be enabled (or disabled)

  4. Brief statement about which lab(s)/domain(s) the software will impact

  5. A brief statement about a "test" input and expected output so that we can do an initial validation.