Roar Policies

Software Acceptable Use Policy (ICDS-ACI-P040)

1.0 Overview

This document defines the policy and guidelines for utilization of software and licenses, software installation, and maintenance, as well as how additional software can be requested and installed for the Institute for Computational and Data Sciences – Advanced Cyber Infrastructure (ICDS-ACI).

2.0 Purpose and Scope

This policy details the management and acceptable use of Roar software and licenses, requesting additional software installation, and user installation of software. This policy is implemented to ensure fair and equitable access to software and licenses for all Roar users; it is not intended to inhibit access to software and licenses. All software resources are to be used for research or teaching purposes which are sanctioned by the University. Anyone violating this policy or the policies referenced below is subject to suspension or termination of their user account.

This policy may be extended or modified as needed. All revised policies will be published online.

3.0 Waivers and Exceptions

Waivers and exceptions to this policy should be coordinated through the ICDS Coordinating Committee and ACI Working Group. Waivers and exceptions may include, but are not limited to, the following:

  • Software Stack modification timeline
  • Additional software support or resources needed that are not captured in the Service Level Agreement (SLA)

These exceptions will be considered by the ICDS staff in conjunction with the ICDS Coordinating Committee as they are received.

4.0 Software Stack Definitions

The Roar architecture is organized into Service Layers into which software may be installed. The software installed on this system fits into one of three categories addressed by this policy: 1) Roar-Maintained Infrastructure stack, 2) Roar-Maintained Application Stack, and 3) User Software Stack. The ICDS-Maintained Infrastructure and Application Stacks are installed and managed by Roar system administrators (system maintainers). Software on the User Software Stack is introduced and maintained by system users, such as the Principal Investigators (PIs) and researchers.

The ICDS-Maintained Infrastructure Stack includes software installed at the system level required for the system to exist. This includes operating systems, resource schedulers (e.g. MOAB), and system monitoring and logging software. The ICDS-Maintained Application Stack consists of application-driving software, such as compilers, communication libraries, and data movement software, and widely used application software, such as Python, R, or COMSOL. The ICDS-Maintained Software Stacks will consist of widely used versions of the software.

The User Software Stack includes software introduced and maintained by investigators and researchers (users) into their own storage space ($HOME, $WORK or $SCRATCH) or into a shared group directory. Investigator (user) software is installed on the software layer. The User Software Stack allows users to keep software that is specialized either in content or in version for their own use. This specialized software can be software that is not widely used around campus and is not installed and maintained for all users by the system administrators. Additionally, both newer and older versions of the system-maintained software can be installed and maintained by users as their research requires. The table below lists the high-level software that is included in the software stacks. Please note that this table is not an all-inclusive list of software.

Summary of Software Stacks
Roar-Maintained Infrastructure Stack Roar-Maintained Application Stack User Software Stack
Operating system (RH, Windows, ESXi, etc.) Communication libraries (MPI, OpenMP) Legacy versions of software (No longer supported at the system level)
Security monitoring and logging (OSSEC) Compilers Bleeding edge versions of software (Not yet widely accepted/used or supported at the system level)
Batch job scheduler (MOAB, Torque) Commonly used software applications (e.g. MATLAB, COMSOL, R, Python etc.) Specialized software (used by small numbers of users)
Configuration management (Puppet, Atlassian) File transfer (Globus) Specialized modules/libraries for use within ACI-maintained software
Satellite server

5.0 System Software Stack Request Timeline and System Installation Guidelines

Roar-Maintained System and Application Software Stacks, or the baseline software, will be updated twice a year in baseline deliveries. Each of these baseline deliveries requires a system outage, of which users are notified in advance. New software or updates to existing software will be installed during these baseline deliveries. Change requests to the Roar-Maintained Infrastructure and Application Stacks should be made no less than six weeks prior to the baseline delivery. The six-week window allows the system maintainers to build a sandbox version of the new environment to run test cases for the various software to ensure smooth transitions. All Roar users will be sent a reminder to provide requests for new software to be included in the Roar baseline delivery at least two weeks in advance of the deadline. Software requests made within six weeks of the system baseline delivery may be denied. However, they will be considered for the following baseline delivery. The system-maintained software may be updated outside of this biannual cycle if security vulnerabilities require immediate action.

5.1 User Software Stack Guidelines

User software introduced into the User Software Stack, i.e., software within a user’s storage space, shall be introduced and maintained by the user or group who introduced the software. Users may put software in their directories at any time provided that the applicable responsibilities and requirements for software use are met, as documented in this policy. The Roar system maintainers are not responsible for any software introduced by the user, unless an existing SLA dictates otherwise. Users are responsible for the maintenance and upgrade of the software introduced, as well as for ensuring that software is free of software vulnerabilities. Furthermore, the user or group introducing the software is responsible for tracking and managing any licenses or use agreements required for software use.

Users are responsible for maintaining and managing their software for the entire lifecycle of the software (i.e., implementation through removal). Furthermore, the Roar system maintainers are not responsible for adverse effects (i.e., version compatibility issues) on user software that arises from modifications made to the Roar-Maintained Software Stack.

Please refer to the Responsibilities and Requirements for Software Use sections below for additional guidance.

5.2 Roar-Maintained Software Stack Installation Guidelines

Roar system maintainers are responsible for installing and managing software in the Roar-Maintained Infrastructure and Application Stacks. Software modifications, additions, and removals from the Roar-Maintained Stacks will be completed during the planned baseline deliveries.

6.0 Responsibilities

Summary of Responsibilities
Action Roar-Maintained Software Stack User Software Stack
Evaluate impacts of new baseline Roar Researcher
Procurement Roar Researcher
Verify license/usage agreements for software Roar Researcher
Track and maintain software list on website Roar N/A
Alert users of software changes Roar N/A
Scan software for vulnerabilities Roar N/A
Remove software that presents security vulnerabilities Roar Roar
Communicate baseline delivery schedule Roar N/A

6.1 Researcher Responsibilities

Any software that is put into users’ group or personal directories as a part of the User Software Stack must meet the following criteria:

  • The software license and usage agreements must be followed.
  • Users will ensure that no vulnerabilities and viruses exist to the extent practical (e.g., malware).
    • Any software that presents a security risk for the system may be removed from the User Software Stack by system administrators.
    • Upon said removal, the user shall be notified of the removal and provided with an explanation of why the software was removed.
    • Repeated or flagrant offenses will also result in the suspension or termination of user accounts.
  • Additional software introduced by users shall be maintained by the users unless otherwise specified in the Roar SLA.

Researcher-requested software to be installed in the Roar-Maintained Infrastructure and Application Stacks must meet the following criteria:

  • User requests for software modifications in the Roar-Maintained Infrastructure and Application Stacks must be submitted to the i-ASK Service Center (
    • Software requests should be made within the timeframe described above in the Software Request Timeframe section.
    • The request type should be identified as “Software” on the ticket request.
  • The software, or version of software, must have required capabilities that software currently on the system-maintained stacks do not provide.
    • Newer versions of software will only be installed when additional or improved capabilities are made.
    • The software must have application to and/or be in use by a large number of users.
    • The software must not introduce an undue maintenance burden, and must be in a mature, stable portion of its lifecycle.

6.2 Roar System Maintainer Responsibilities

Roar system maintainers (e.g., administrators, operations engineers, system engineers, etc.) are responsible for installing and maintaining the Roar-Maintained Infrastructure and Application Stacks provided with the baseline deliveries. Responsibilities include:

  • Evaluating software for vulnerabilities prior to its installation on the Roar-Maintained Infrastructure and Application Stacks.
  • Deploying and maintaining the Roar-Maintained Infrastructure and Application Stacks as part of the ACI system, including:
    • Installing and maintaining software on the Roar-Maintained Infrastructure and Application Stacks.
    • Upon release of a new version, installing the new version on its developmental system. Once verified, it will be deployed on the production systems. At this time, the oldest version will be removed from the production systems. Roar will maintain at least the current release and one previous version of the software package. Users requiring older versions may have this software transitioned into their local directories (User Software Stack).
    • Performing routine security/vulnerability patching through automated mechanisms.
  • Communicating through email to all users of the system any changes to the Roar-Maintained Infrastructure and Application Software Stacks, including new software packages, updated versions (e.g., Operating System upgrades, etc.), and removals. Login prompts will be used to provide reminders; however, email will be the main communication route that ICDS-ACI uses.
  • Periodically scanning the system for software vulnerabilities.
  • Maintaining a list of the Roar software installed on the Roar-Maintained Infrastructure and Application Stacks on the ICDS website.
  • Providing assistance in moving legacy software (i.e. software that is at least two releases out of date) from the ACI-Maintained Stacks to the User Software Stack.
    • Roar system maintainers will provide assistance in the transition of the software to the User Software Stack. Once the transition has been completed, the user assumes all responsibilities for that software (i.e. licensing, use compliance, maintenance).
  • Removing software applications and/or libraries, if necessary. Roar reserves the right to remove any software application and/or library for the following reasons:
    • Security vulnerabilities – Software will be removed immediately without prior warning. After removal is complete the software owner(s) will be notified of the removal with an explanation. ICDS will work with the software owner(s) to evaluate and mitigate the vulnerability. Once the vulnerability has been addressed, the software may be reintroduced into the Roar-Maintained Application Stack.
    • Degradation of system operations – Impacts to system operations will be evaluated to determine what and who have been impacted. In the event it is determined that users are not able to complete their research, and/or system availability and integrity have been compromised, the software will be isolated immediately. The software requestor will be notified prior to isolating the software.
    • Violation of license agreements.
    • Issues that impact the integrity, availability, or confidentiality of the Roar system functionality.
  • Providing assistance to users needing to compile code.
    • Requests for assistance must be submitted through the i-Ask Service Center.

7.0 Requirements for Software Use

To ensure that its software assets derive maximum benefit to the Roar user community allowing fair and equitable use, and to ensure that Roar and its users adhere to a standard software policy, Roar users:

  • Shall understand, agree to, and comply with all security policies governing Penn State and Roar Computer and Network Resources, as well as all federal, state, and local laws, including laws applicable to the use of computer facilities, electronically encoded data, and computer software.
  • Shall use the system to further research objectives and not for personal gain (i.e., activities such as Bitcoin Mining, etc.).
  • Shall not try to exploit and/or probe for vulnerabilities or weaknesses within the system.
  • Shall evaluate software to the extent practical for potential and known vulnerabilities prior to introducing software in the User Software Stack.
  • Shall assume all responsibility of managing and procuring license(s), as well as ensuring acceptable use, for any software residing in the User Software Stack.
  • Shall not duplicate copyrighted software not allowed by the software license, except for backup and archival purposes.
  • Shall notify the Roar i-ASK Service Center ( of evidence of the use or distribution of unauthorized software. You may not loan or give to anyone any software licensed to ICDS. Under no circumstances may any user use the Roar licensed software for purposes other than educational or research purposes sanctioned by the University.

Academic License Agreements that reference export controls may require the following notification that all users must comply to applicable U.S. export control laws and regulations. Please see the website for a list of these notifications including:

“NOTICE: The terms of the Academic License to this software specifically prohibit the use of software (reference in conjunction with the design, development, production, handling, operation, maintenance, storage, detection, identification, or dissemination of chemical, biological, or nuclear weapons or nuclear explosive devices, or the development, production, maintenance, or storage of missiles capable of delivering such weapons, or for any prohibited military end-uses. In addition, the Academic License terms require that all users be notified that use of this software is subject to applicable U.S. export control laws and regulations and that users must comply with such laws in their use of this software. This notification can be accomplished either in print or via an on-screen display of this notification. Questions about these license requirements and/or export compliance at Penn State in general may be directed to the University Export Compliance Office at”

8.0 Reference

This policy applies to any person who utilizes resources that are provided and managed by Roar. In the absence of specific Roar policies, Pennsylvania State University policies apply. This policy augments the following Pennsylvania State University and Roar policies:

University Policies

  • AD11 – University Policy on Confidentiality of Student Records
  • AD20 – Computer and Network Security
  • AD23 – Use of Institutional Data
  • AD71 – Data Categorization
  • ADG01 – Glossary of Computerized Data and System Terminology
  • ADG02 – Computer Facility Security
  • HR102 – Separation and Transfer Protocol
  • RA40 – Compliance with Federal Export Regulations for Sponsored Research Efforts

Roar Policies

  • ICDS-ACI P020 – User Account Policy
  • ICDS-ACI P030 – Data Retention Policy
  • ICDS-ACI P060 – ICDS-ACI SLA Terms and Conditions Policy


ACI-bRoar sub-system configured to execute jobs submitted to a variety of queues, i.e. batch processing.
ACI-uRoar User-Specific “Development/Test” interactive subsystem where PIs may specify a system configuration for user-specific interactive sessions, including root access and user-defined software stack.
BatchExecuting or processing of a series of programs (jobs) on a system without manual intervention.
CoreData processing unit within a server. The total cores per server is dependent upon the vendor’s architecture of the server.
Core AllocationAmount of physical compute resources purchased by or granted to a user through Roar plans.
F&AFacilities and Administration charge, sometimes referred to as “indirect” or “overhead”.
GPFSGeneral Parallel File System.
GroupA self-defined set of multiple users—for example, students and researchers in a faculty member’s lab. Such rights as access to storage and allocation of resources can be delegated in an organized fashion by the PI.
Group StorageDedicated disk space for storing group-related data or research.
Guaranteed Response TimeThe maximum time that it takes for a job to start execution after submission to a queue.
Home DirectoryA user’s dedicated disk space for storing personal files, directories and programs. Directory that a user is taken to after logging into the system.
ICDS-ACIInstitute for Computational and Data Sciences – Advanced Cyber Infrastructure.
ICDS-ACI-BurstQueue to allow usage of compute resources in the ACI-b subsystem above a PI’s physical allocation that are needed for a short time period.
ICDS-ACI-GuaranteedQueue providing access to the ACI-b subsystem within a guaranteed time, provided request is within a PI’s physical allocation.
ICDS-ACI-OpenQueue to provide user access to idle ACI-b resources that can be used during times when supply exceeds demand.
Legacy SystemsPre-2015 ICDS computing systems, such as the Lion-X clusters.
Login NodesFront-end servers used to log in to the Roar compute system.
NASNetwork-Attached Storage.
PIPrincipal or Primary Investigator. Person, such as faculty, who is authorized to direct all of his or her research Roar resources, e.g. access, storage, compute.
Pre-emptionThe act of pausing or stopping a job that is currently processing in order to fulfill terms and conditions to other users under service level agreements.
Scratch DirectoryDisk space dedicated for temporary storage of data.
Service Level Agreement (SLA)Agreement between ICDS and Research PI in relation to research Roar resources, e.g. access, storage, compute.
SubsystemA unit or device that is part of a larger system, e.g., ACI-b.
SystemThe computing engine along with the software, storage, network, and peripheral devices that are necessary to make the computer function, e.g., Roar.
UserA person, such as a student or faculty, who has a user account to use the Roar resources.
User AccountThe means by which a user can access a computer system. Roar has four distinct user accounts: PI, Student, Staff, and Sponsored Guests.
Wall TimeA queue parameter that is set to define the maximum allowable execution time for a job once it has started.
Work DirectoryUser’s dedicated disk space for storing research data.