Skip to content

Key Policies

Software Installation Request Policy

The Anvil team will go to every reasonable effort to provide a broadly useful set of popular software packages for research cluster users. However, many domain-specific packages that may only be of use to single users or small groups of users are beyond the capacity of staff to fully maintain and support. Please consider the following if you require software that is not available via the module command:

If your lab is the only user of a software package, Anvil staff may recommend that you install your software privately, either in your home directory or in your allocation project space. If you need help installing software, the Anvil support team may be able to provide limited help. As more users request a particular piece of software, Anvil may decide to provide the software centrally. Matlab, Python (Anaconda), NAMD, GROMACS, and R are all examples of frequently requested and used centrally-installed software. Python modules that are available through the Anaconda distribution will be installed through it. Anvil staff may recommend you install other Python modules privately. If you're not sure how your software request should be handled or need help installing software please contact us at Help Desk..

Helpful Tips

  • We will strive to ensure that Anvil serves as a valuable resource to the national research community. We hope that you the user will assist us by making note of the following:
  • You share Anvil with thousands of other users, and what you do on the system affects others. Exercise good citizenship to ensure that your activity does not adversely impact the system and the research community with whom you share it. For instance: do not run jobs on the login nodes and do not stress the filesystem.
  • Help us serve you better by filing informative help desk tickets. Before submitting a help desk ticket do check what the user guide and other documentation say. Search the internet for key phrases in your error logs; that's probably what the consultants answering your ticket are going to do. What have you changed since the last time your job succeeded?
  • Describe your issue as precisely and completely as you can: what you did, what happened, verbatim error messages, other meaningful output. When appropriate, include the information a consultant would need to find your artifacts and understand your workflow: e.g. the directory containing your build and/or job script; the modules you were using; relevant job numbers; and recent changes in your workflow that could affect or explain the behavior you're observing.
  • Have realistic expectations. Consultants can address system issues and answer questions about Anvil. But they can't teach parallel programming in a ticket and may know nothing about the package you downloaded. They may offer general advice that will help you build, debug, optimize, or modify your code, but you shouldn't expect them to do these things for you.
  • Be patient. It may take a business day for a consultant to get back to you, especially if your issue is complex. It might take an exchange or two before you and the consultant are on the same page. If the admins disable your account, it's not punitive. When the file system is in danger of crashing, or a login node hangs, they don't have time to notify you before taking action.

Acceptable Purdue IT Research Resource Use

RCAC requires all users of its research computing resources to submit their jobs through the provided queuing systems. Do not attempt to bypass or hinder these systems. Documentation for the queuing systems on each major computing resource is available on this web site. Please be as accurate as possible about the resources which your jobs will require, as this will help the system run more efficiently and may help your jobs run more quickly. You must specify the actual number of processor cores that each job will use when submitting your jobs. Failure to do so could result in poor performance and may adversely impact other users' work.

All users of research resources must also comply with Purdue IT's Resource Acceptable Use Policy, Purdue University Policy V.4.1, as well as Purdue's Remote Access to IT Resources Policy, Purdue University Policy V.1.6.

Data about activity on research computing resources is routinely logged, archived and analyzed, to provide feedback about system performance, resource and software utilization, and better optimize the resources. This includes, but not limited to, environment modules loaded, applications run, hardware performance counters, disk storage consumed, and the contents of batch job scripts.

Scratch File Purging

All users of research computing systems are provided a scratch directory. Research scratch directories are available for short-term storage of files. There is no backup service for scratch directories, and files not accessed or modified in the last 30 days will be removed. In the event of a disk crash or file removal, files in scratch directories are not recoverable. Please be sure to save copies of all important files elsewhere (e.g. your $PROJECT space) on a regular basis.

Purge Policy

Files listed by purgelist will be permanently removed on the date shown. Deletion of files begins on the morning of the date shown by purgelist shortly after midnight. If you need to keep any of these files, please copy them elsewhere. Remember to account for transfer time of your files and do not wait until the last minute to copy files off scratch space.

Scratch Space Considerations

It is important to keep in mind that cluster scratch space is for limited-duration, high-performance storage of data for running jobs or workflows. Old data in scratch filesystems is occasionally purged to keep the filesystem from being fragmented or filling up. Scratch is intended to be a space in which to run your jobs, and not used as long-term storage of data, applications, or other files.

Please keep in mind that any scratch filesystem is engineered for capacity and high performance, and are not protected from any kind of data loss by any backup technology. While research computing scratch filesystems are engineered to be fault-tolerant and reliable, some types of failures can result in data loss.

Acceptable Use

The scratch filesystems are for limited-duration, high-performance storage of data for running jobs or workflows and are explicitly not intended to be used as a long-term storage. Doing so, or engaging in measures to circumvent purging, is adversely affecting all users of the system and is considered a violation of Acceptable Research Resource Use.