LONI Usage Policy

Last revised: 5 January 2011

1. Introduction

The LONI computing facilities, encompassing its hardware, software, network connections, and data, are a vital but limited resource for the Louisiana community. Therefore the LONI sites have an obligation to protect their facilities and ensure they are used properly. Allocations are used to assure equitable consumption of system resources, while personal access to the systems is controlled via user accounts. You, personally, are constrained by legal and other obligations to protect resources and the intellectual property of others on the systems.

Given the extensive nature of these resources, responsibilities are attached to the right of access. Responsible user conduct is required so as to assure fair access by all researchers. Failure to use these resources properly may result in various penalties, including, but not limited to, loss of access, academic, civil and/or criminal action.

Back to Top

2. Requirements

2.1. Individual Account Management

You have the responsibility to protect your account from unauthorized access, and for the proper expenditure of allocated resources. Tools are provided to help you manage your resources, but you are responsible for using these tools properly.

2.1.1. Valid Contact Email

Every account has a contact email address associated with it, and this address must be issued by a LONI institution. Email is used as the primary communication channel between LSU@HPC and the user. The user is responsible for keeping this address up to date. In the event that an address is discovered to be invalid or unresponsive, the associated user account will be locked until the issue is resolved.

2.1.2. No Account Sharing

Your account is for your personal use only. It is not to be shared with others; neither students nor other collaborators. Others who need system access must request their own account. User authentication certificates, if they are used, are considered personal accounts and are not to be shared. Any activity indicating account sharing will result in the account being locked until remedial action is taken. Repeated misuse may result in permanent loss of system access.

2.1.3. Protecting Passwords

Your passwords and certificates are the keys to account access. You are responsible for their protection and proper use. Protective behavior includes:

• never sharing passwords
• never writing passwords down where they can be easily found
• never using tools which expose passwords on the network (e.g. telnet).

See Guidelines, Section 5, for more information.

The private key portion of an authentication certificate is the equivalent of a password. If you use certificates, you are responsible for ensuring that file and directory permissions prevent others from reading or copying any private keys.

2.1.4. Mailing List Membership

While an account is active, the user is required to be a member of the users@loni.org mailing list. This list is used to notify everyone of important changes and events. List membership is automatic upon creation of the account, and persists until the account is deactivated. Anyone wishing to be removed from the list should send an email to sys-help@loni.org and request that their account be terminated. This will result in removal from the list.

2.2. Fair Use

Access to a system does not grant you blanket authorization for any and all activity. You must recognize that reasonable use may vary from machine to machine within a system, depending on the function of the machine. Machines in a cluster serve one of two basic functions.

2.2.1. Computational Nodes

These are the nodes which perform the intended heavy computational work of a cluster. They are accessed via the job scheduler (e.g. LoadLevel or PBS) through the submission of job control scripts. Computational tasks are never to be run on the cluster head nodes, as this has the potential of impairing operation of the entire system.

2.2.2. Head Nodes

Head nodes are used for the interactive work required to prepare a computational task. Appropriate work on the head nodes includes: light editing, compiling, post analysis previewing, and job script creation. Extensive post processing should be done on the compute nodes. Any processing on the head nodes which adversely impacts system operation is subject to preemptory termination. Repeated abuse may result in the locking of user accounts or other administrative action as deemed appropriate.

2.2.3. Authorized Use

Authorized use of the system is defined by the purpose outlined in the proposal on which the usage allocation is based. Your use of the account is limited to activities reasonably required to accomplish that purpose.

2.2.4. Unacceptable Behaviors

The following activities are explicitly considered unacceptable and are subject to the penalties outlined below:

• using, or attempting to use, LONI computing resources without a valid allocation, or for purposes other than those stated in the allocation proposal.
• tampering with or obstructing the operation of the facilities.
• reading, changing, distributing, or copying others' data or software without authorization.
• using LONI resources to attempt to gain unauthorized access to other (non-LONI) sites.
• activities in violation of local or federal law

2.3. Reporting Suspicious Activity

You are responsible for reporting, as soon as possible, any suspicious activity you notice on your account, and exposure or compromise of passwords, passphrases, or certificates. See Section 5 for reporting procedures.

2.4. Data Confidentiality

You are responsible to ensure the confidentiality of any data you use on LONI resources that is restricted from general public access. LONI sites provide technology to preserve the confidentiality of data, but it is your responsibility to use that technology appropriately. Such data may include:

• Intellectual property, such as report drafts or research in progress,
• Proprietary data, such as data owned by a specific company, or licensed applications.
• Regulated data, such as medical, personal identifying information, or student records.

It is your responsibility to be aware of any requirements on a data set and verify that a given LONI site can provide appropriate protection before attempting to use it. Be aware that some sites may be subject to state laws which impose requirements on data stored on those sites.

2.5. Acknowledgment

Papers, publications, and web pages of any material, whether copyrighted or not, based on or developed under LONI-supported projects must acknowledge this support by including the following statement:

Portions of this research were conducted with high performance computational resources provided by the Louisiana Optical Network Infrastructure (http://www.loni.org).

2.6. Software Development

Software developed with allocations approved by LONI or by proxy, via the allocations processes governing allocation of LONI resources, is subject to intellectual property rights as established by the LSU and participating institutions. Questions should be directed to the Director, Office of Intellectual Property, LSU, or the user’s home institutution.

2.7. Publication

Work performed under a peer-reviewed allocation must be published in the open literature.

2.8. Non-Academic User Requirements

Non-academic (corporate/industrial, government, etc.) users frequently have more stringent usage requirements than those that might be provided by the LONI as a whole or by a particular site within LONI. It is the user's responsibility to assure the resources used satisfy the requirements of their organization. For LSU users, see: Office of Intellectual Property site.

2.9. Software Licenses

All software used on LONI systems must be appropriately acquired and used according to the specified licensing. Possession or use of illegally copied software is prohibited. Likewise users shall not copy copyrighted software or materials, except as permitted by the owner or the copyright. Some installed software may require special authorization in order to be used. Users must abide by the licensing requirements and protect it from misuse.

2.10. Final Reports

Requests for subsequent allocation awards will not be allowed until an end of project report has been received for all prior awards. Copies of prior final reports must be attachmented to the submitted proposal.

2.11. Additional Requirements

Individual sites may be subject to organizational policies with additional requirements beyond this policy. Those organizations will make those policies available. It is your responsibility to be aware of and abide by those policies.

3. Penalties

Failure to abide by these policies may result in a variety of penalties imposed.

3.1. Account Suspension/Revocation

Accounts may be temporarily suspended or permanently revoked if compromised or abused. Your account may be suspended without advance notice if there is suspicion of account compromise, system compromise, or malicious or illegal activity.

3.2. Loss of Allocation

Unauthorized behavior can result in loss of your current allocation, and may lead to the inability to obtain future allocations.

3.3. Administrative Action

Unauthorized activity may be reported to your PI, your advisor, or your home institution for administrative review and action.

3.4. Civil Penalties

Civil remedies may be pursued to recoup costs incurred from unauthorized use of resources or incident response due to compromise or malicious activity.

3.5. Criminal Penalties

Activities in violation of federal, state, or local law may be reported to the appropriate authorities for investigation and prosecution.

4. Disclaimers

4.1. Additional requirements

As stated in Section 2.5, individual LONI sites may be subject to requirements beyond the scope of this document. However, it is your responsibility to identify if such requirements exist.

4.2. Support/Diagnostic Access

LONI site personnel may review files for the purposes of aiding an individual or providing diagnostic investigation for LONI systems. User activity may be monitored as allowed under policy and law for the protection of data and resources. Any or all files on LONI systems may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to authorized site or law enforcement personnel, as well as authorized officials of other agencies, both foreign and domestic. By using LONI systems, users acknowledge and consent to this activity at the discretion of authorized site personnel.

4.3. Access Notification

Access to user data and communications will not normally be performed without explicit authorization and/or advance notice unless exigent circumstances exist. Post-incident notification will be provided in such cases.

5. Guidelines

The following are suggestions for helping maintain the security of your account.

5.1. Password Management

• Do not write down your password where it can be easily found and/or associated with your account.
• Do not tell anyone your password, not even LONI support staff. Support staff will never need your password, will never ask for it, and will never send a password in e-mail, set them to a requested string, or perform any other activity which could reveal a password.
• If someone insists they need your password to do something, report it to the LONI helpdesk: sys-help@loni.org.
• Do not store your password(s) in unencrypted files or even in encrypted files if possible.
• Pick passwords that are difficult to guess. Birthdays, family names, and single dictionary words are examples of easily guessed passwords.
• Change your password periodically, even if you have no reason to believe that anyone else has it.

5.2. Reporting Suspicious Activity

5.2.1. Password Exposure

If you think your password may have been compromised or exposed, but have no reason to believe that your account has been used, change your password immediately.

5.2.2. Certificate Exposure

If you believe your certificate has been exposed, revoke your certificate and have a new one issued.

5.2.3. Account Compromise or Suspicious Activity

If you believe your account has been compromised or find signs of suspicious activity, take the following actions:

• notify the LONI helpdesk immediately (sys-help@loni.org)
• do not modify files found in your account
• do not execute unknown programs you might find
• if possible, do not use your account until the issue is resolved

Some indications of account compromise include:

• files in your home directory or project areas which you did not create
• alteration or deletion of your files not done by you
• discrepancies between your allocation balance and what you think you have used

6. Contacts

The central point of contact for any problems and concerns with regards to this policy is the LONI help desk which can be reach at sys-help@loni.org. Other modes of contact are listed on the LONI web site help page.

LONI User Allocation and Account Policy

Last revised: 10 Apr 2015.

1. Accounts and Allocations

LONI (Louisiana Optical Network Infrastructure) maintains a high speed optical network that connects most of the institutions of higher education in the State of Louisiana as well as several other entities. LONI also provides high performance computing (HPC) systems to support research, education, and economic development in the State. Detailed information about LONI can be found on the LONI web site. LONI controls access to these resources via a formal user account and resource allocation process. All decisions in these matters are made by the LONI Resource Allocation Committee (LRAC) made up of representives from each of the LONI member organizations.

Gaining access to LONI resources, be it computer time or data storage, involves a two step process. Since all interactions with the systems are controlled by user account, the first step requires placing a request for one. Only one account is needed to access any of the LONI systems, as well as the process management tools provided on the various web sites. All faculty and research staff are eligible for user accounts, which may be applied for on-line.. Be aware that all usage is governed by the LONI Usage Policy. Student and research collaborators are eligible for accounts, but they must be sponsored by a faculty member.

The second step in the access process is to associate a user account with a resource allocation. Compute time is a finite resource, so access is controlled by an allocation process. An allocation provides a block of computational time, measured in Service Units of 1 wallclock hour on 1 CPU processor core. Likewise, storage space (on some systems) is controlled by a quota system, and allows for storing and sharing large data sets. The remainder of this document will discuss allocations, while use of storage is discussed in more detail in the LONI Storage Policy document.

Allocations are awarded through a proposal submitted by a principle investigator (PI). Full-time faculty and research staff at LONI Member and Associate institutions are eligible to serve as a PI for allocation purposes. Resource allocations for undergraduate and graduate students should be requested by a faculty advisor. The LONI Management Council reserves the right to designate others for PI eligibility. Once awarded, the PI is able to authorize other users to charge resource consumption against the allocation. The PI is responsible for all authorizations, but may formally delegate some other user to manage this process. Once a user account is authorized to use an allocation, the user is enabled to submit jobs or otherwise expend the allocation resources. This implies that a user must be authorized for at least one non-expired allocation before the systems can be used. Likewise, a user account may be authorized to use multiple allocations. It becomes the responsibility of the PI and user to make sure the appropriate allocation is charged for work.

The second step involves associating user accounts with specific allocations against which they can charge resource usage. To accomplish this, tools are made available to the PI to control authorization of users on their allocations. The PI associates an email address with an allocation to which all user account requests are sent for authorization. The PI is responsible for all authorizations, but may formally delegate someone to manage this process. Once a user account is authorized to use an allocation, the user is allowed to submit jobs or otherwise expend the allocation. This implies that a user must be authorized for at least one non-expired allocation before the systems can be used. Likewise, a user account may be authorized to use multiple allocations. It becomes the joint responsibility of the PI and user to make sure the appropriate allocation is charged for work performed.

A single machine will have multiple nodes (individual servers) available, with multiple cores within each node. This allows many cores to be used for a single parallel processing job, but can lead to not-so-obvious charges. For example, running for 1 hour using 8 cores on an 8-core node consumes 8 SU's. On the other hand, running for 1 hour on 1 core of the same 8 core node, which allows the single core to access all of the node memory, also consumes 8 SU's. In simple terms, the number of cores that are reserved for a job, and hence are unavailable to others, is the number used to calculate SU usage.

2. The Allocation Process

LONI resources are partitioned by category, and all allocation proposals go through the LONI Resource Allocation Committee (LRAC). The LRAC represents three distinct approval authorities: individual member institutions; the LONI Management Council (LMC), represented by the LONI director; and the LRAC as a panel. Table 1 shows the distribution of LONI resources by category:

All allocations have a duration of one year, and are considered active until they expire regardless of current balance. They are considered valid so long as they have a positive balance and have not yet expired. Small Allocations may be awarded at any time, while Large Allocations are granted at the beginning of every calendar quarter. Application deadlines for Large Allocations are one month prior to the start date, as summarized in Table 2.

A PI may request, or be requested, to make a formal presentation to the allocation authority in conjunction with their proposal submission. At the end of a large allocation, a report in PDF format must be uploaded to the allocation web site. Requests for new large allocations will not be approved until reports for expired allocations have been submitted. The report should detail:

1. If the goals of the proposed work were accomplished
2. Any major results or outcomes
3. All resulting publications/presentations.

To facilitate management of proposals, they are identified as belonging to one of several classes (Table 3).

2.1 Proposal Requirements

All requests for an allocation are made via the LONI web interface to the LRAC. Small allocations require only the data requested on the form. Large allocations must attach a more extensive proposal in PDF format. The proposal is expected to be 5 pages or less, and concentrate on justifying the computational resources requested. The following outline should be followed:

1. Problem Statement - section limited to 1 page, or less, describing the desired outcomes of the project.
2. Background - section limited to 1 page or less, describing how the resources will be used to address the problem (i.e. student access for course work, specific models, etc.).
3. Methodology - section limited to 1 page, or less, describing the computational methodology that will be used. This should include the applications required.
4. Research Plan - section limited to 1 page, or less, describing the research schedule, including the anticipated expenditure of granted resources. Allocations are assumed to be uniformly consumed over their lifetime. If this will not be the case, an estimate of expenditure by calendar quarter is required.
5. Requirements Analysis - section limited to 2 pages, or less, detailing the basis for the requested computer time. Requests for large allocations must exhibit an understanding of application efficiency, scaling, and provide accurate estimations of the SU requirements.
6. Attachments - Supplementary information relating to the proposal, such as copies of awarded grants which will be supported by the allocation, and lists of resulting publications. This same attachment area is used for submitting reports at the end of large allocations.

Please note that section page limits are suggestions, but the maximum proposal page limit remains 5, not including any Attachments. The page limit was chosen with an eye to making it relatively easy to compose an allocation request, or to modify and reuse a successful application made to another center.

Project allocations are competitively reviewed and granted based upon the description of the proposed research and use of the available technology. They are not vetted on scientific merit. For Large Allocations, priority is given to funded research. All decisions made by the LRAC are deemed final. Appeals can be directed to the LMC or the member institution council representative.

2.2 Allocation Management

User accounts without access to a valid allocation will be blocked from submitting work on the systems. There is no mechanism for extending an allocation beyond one year, nor for adding resources once an allocation has been expended.

User accounts must be associated with a valid allocation, and if not, will be retained for a maximum of 1 year pending authorization against a renewed or different allocation. With these restrictions in mind, the PI is required to use the tools provided to monitor system usage and control authorization of project member accounts. PI's are strongly advised to carefully budget their usage appropriately throughout the year. Automatic reminder emails will be sent by the management system as an allocation nears expiration. PI's are ultimately responsible for assuring that a current and actively monitored management email address has been assigned to each allocation.

At the end of a Large allocation, a short report must be submitted, as detailed above. Failure to submit this report may be used in the consideration of future allocations.

2.3 Early Allocation Access

If a PI who has already been awarded a Large allocation by the LRAC puts in a new request, and there is a good reason to start the project before the next cycle, then the local representative can request staff to award as much as 25% of the project request immediately. Justification must be provided in the proposal. The LRAC committee must then be made aware of this action and its reasons by the local representative using the "LONI Allocations" listerver.

3. Machine Access Policy

3.1 Job Queueing

Various workload balancing algorithms are used to determine how jobs are assigned resources on a given machine. The way a job is handled is determined by the job queue it is submitted to. Efficient use of the queuing system requires that users request runtimes consistent with estimated runtimes of their jobs. In particular, requesting more time than is necessary for a particular job can lead to inefficient and unfair queuing. Therefore, users that routinely request more time than is needed for their jobs are subject to a “priority penalty” that will lower the priority of their jobs. Each system sets a maximum number of jobs that a single user may have running without special permission (see below). There is no limit to the number of jobs that are particular use may have queued. Users that wish to obtain a higher priority for their jobs may use special priority queues (see below).

3.2. Queues

The processors on the systems are further subdivided into preemptory and dedicated pools. Certain mission critical applications, such as storm surge prediction during a hurricane threat, are granted immediate access to processors in the preemptory pool. Processors in the dedicated pool are used to run all other job types. The processors are accessed through one of 6 different types of job queue. This allows for different combinations of processors and job characteristics. Every type may not be available on every machine.

3.2.1. Preempt Queue

The preempt queue controls access to the preemptory pool. Authorized applications submitted to this queue will cause the termination of all other user applications running on preemptory nodes.

3.2.2. Checkpt Queue

The checkpt queue controls access to nodes in both the dedicated and preemptory pool. Jobs running in this queue may be subject to termination by the preempt queue, thus are implicitly assumed to support restarts based on periodically saved information. No refunds of lost SU's are offered if jobs in the checkpt queue are terminated by preemption. The user running jobs without restart capability assume this risk. However, the benefits from using this queue include access to larger numbers of nodes, and/or faster throughput, depending on how busy the queue is.

3.2.3. Workq Queue

The workq queue controls access to nodes in the dedicated pool. Jobs in the work queue will run until they terminate as planned, their requested run time has expired, or they stop due to an abnormal system failure. Jobs which are terminated due to system errors beyond the user's control may be subject to refund of expended SU's. Poor planning is not considered grounds for a refund.

3.2.4 Single Queue

The single queue allows several users to share the resources of a single node. The resource share given to a user is determined by how many cores the job requests.

3.2.5. Priority Queue

The priority queue controls nodes in the dedicated pool, but allows applications to be given higher priority with prior approval. Approval may be granted during training sessions, for demonstration purposes, or other special needs. The SUs charged will be adjusted by a factor of 1.3, and no more than 20% of an allocation may be expended in the queue. Requests for priority access should be directed to sys-help@loni.org. This queue does not impact other running user jobs, but will delay the start of lower priority jobs already in the queue.

3.2.5. Queue Availability

The availability of the queues may be impacted by system maintenance and servicing. The appropriate job management commands can be used to check their status in real time. The maximum time allowed in the queues may be adjusted from time to time in order to improve overall utilization of the machines.

3.3. Storage

Disk space usage is controlled in one of 3 ways. The /home file system is quota controlled. A large pool of shared space is provided in the /work file system. Data in it is purged periodically, and users are cautioned to treat it as large, but temporary, storage space. Storage on the /project file system is quota controlled and may be requested via the allocation process. It serves as longer term (12 months at a time, subject to renewal and current demand) storage for very large data sets. It also supports user groups for sharing access to the data. For more details, see the separate LONI Storage Policy

3.4. Special Requests

A request for special access to LONI machines (such as usage of all nodes on a machine or exceptionally long runs) must be explicitly stated in the proposal for LONI resources. Appeals to the decision of the LRAC may be made to the LONI Management Council.

4. Resource Allocation Committee Members

The current LRAC members are shown in Table 4.

Each member holds approval authority for their respective institution. The LONI Director is also a member, and holds approval authority for the LONI Management Council.

LONI Storage Policy

Last revised: 11 December 2014

1. Storage Systems

Available storage on LONI high performance computing machines is divided into six file systems (Table 1).

All file systems share a common characteristic. When they are too full, system performance begins to suffer. Similarly, placing too many individual files in a directory degrades performance. System management activities are aimed at keeping the different file systems below 80% of capacity. It is strongly recommended that users hold file counts below 1,000, and never exceed 10,000, per subdirectory. If atypical usage begins to impact performance, individual users may be contacted and asked to help resolve the issue. When performance or capacity issues become significant, system management may intervene by requiring users to offload files, stopping jobs, or take other actions to ensure the stability and continued operation of the system.

Management makes every effort to avoid data loss. In the event of a failure, we will make every effort to recover data. However, the volume of data housed makes it impractical to provide system-wide data backup. Users are expected to safeguard their own data by making sure that all important code, scripts, documents and data are transferred to another location in a timely manner. The use of inexpensive, high capacity external hard drives attached to a local workstation is highly recommended for individual user backup.

2. File System Details

2.1 /var/scratch

/var/scratch space is provided on all compute nodes, and is local to each node (i.e. files stored in /var/scratch cannot be accessed by other nodes). The size of this file system will vary from system to system, and possibly across nodes within a system. This is the preferred place to put any intermediate files required while a job is executing. Once the job ends, the files it stores in /var/scratch are subject to deletion. Users should not have any expectation that files will exist after a job terminates, and are expected to move the data from /var/scratch to their /work or /home directory as part of the clean up process in their job script.

2.2 /work

/work is the primary file storage area to utilize when running jobs. /work is a common file system that all system nodes have access to. It is the recommended location for input files, checkpoint files, other job output, as well as related data files. Files on /work are not backed up, making the safekeeping of data the responsibility of the user.

User may consume as much space as needed to run jobs, but must be aware that since the /work file systems are fully shared, they are subject to purge if they become overfull. If capacity approaches 80%, an automatic purge process is started by management. This process targets files with the oldest age and size, removing them in turn until the capacity drops to an acceptable level. The purge process will normal occur once per month, as necessary. In short, use the space required, but clean up afterwards. See the description of /project space below for longer term storage options.

2.3 /home

All user home directories are located in the /home file system. /home is intended for the user to store source code, executables, and scripts. /home maybe considered “persistent” storage. The data here should remain as long as the user has a valid account on the system. /home will always have a storage quota, and is clearly a hard limit. While /home is not subject to management activities controlling capacity and performance, it should not be considered permanent storage, as system failure may result in the loss of information. Users should arrange for backing up their own data.

2.4 Project

The /project file system may be available on some systems, and provides space specific to a project. /project space allocations must be requested, and they are available for a limited time period. To qualify as the PI of a storage allocation, the user must satisfy the PI qualifications of a computational allocation and must have an active computational allocation when the request is submitted. Allocations are typically 12 months or less. Two months before an allocation expires, the user will be notified by email. Users may request to have the allocation extended. Renewal requests should be submitted at least 1 month prior to expiration to allow decision and planning time. If the storage allocation is not extended, the user will have 1 month after the expiration date to off-load their data. Users should have no expectation that data will persist after a project’s expiration, thus alternate safe keeping and data protection actions must be taken in advance.

3. System Specific Information

4. Job Use

On all systems, jobs must be run from the /work file systems. Running jobs from the /home or /project file systems is strongly discouraged. Files should be copied from /home or /project space to /work before a job is executed, and back when a job terminates, to avoid excessive I/O during execution that degrades system performance.

5. /project Allocation Requests

Limitations: Space /project file system by request only for periods of 12 months. A request for initial or renewal allocation is made via a web form as described below. In the interest of fairness, renewals are subject to availability and competing requests.

How to Apply: A storage allocation may be requested by completing a web form. The provided information should fully justify the need for the storage, and indicate how the data will be handled in the event the allocation can not be renewed. A user group can be set up for sharing access to the space if the requestor includes a list of user names.

Allocation Class: Allocations are divided into 3 classes, each with a separate approval authority (Table 3). All storage allocation requests are limited by the available space, and justifications must be commensurate with the amount of space required.

Requests that must be approved by the LONI Resource Allocation Committee will be forwarded to allocations@loni.org.

Researchers are asked to acknowledge their use of LONI resources in any publications or reports that result from their research. The following statement should be included in any such work:

Portions of this research were conducted with high performance computational resources provided by the Louisiana Optical Network Infrastructure ( http://www.loni.org).