32b executable
|
Executable binaries (user applications) with 32b (4B) virtual memory addressing. Note that this is independent of the number of bytes (4 our 8) utilized for floating-point number representation and arithmetic.
|
64b executable
|
Executable binaries (user applications) with 64b (8B) virtual memory addressing. Note that this is independent of the number of bytes (4 our 8) utilized for floating-point number representation and arithmetic. Note that all user applications should be compiled, loaded with Offeror supplied libraries and executed with 64b virtual memory addressing by default.
|
API
(Application Programming Interface)
|
Syntax and semantics for invoking services from within an executing application. All APIs will be available to both Fortran and C programs, although implementation issues (such as whether the Fortran routines are simply wrappers for calling C routines) are up to the supplier.
|
Baseline Languages
|
The Baseline Languages are Fortran03, C, C++ and Python.
|
|
|
BIOS
|
Basic Input-Output System (BIOS) is low level (typically assembly language) code usually held in flash memory on the node that tests and functions the hardware upon power-up or reset or reboot and loads the operating system.
|
BOS
|
Base Operating System (BOS). Linux (LSB 3.1) compliant Operating System run on the ION, SN and LN.
|
CDTI
|
The hierarchal Code Development Tools Infrastructure (CDTI) components are distributed throughout the Sequoia system. Individual code development tool “front-end” components that interact with the user execute on the LN (although the display may be remoted via an X-Window). Code development tool communications mechanisms interface the tool “front-ends” running on the LN with the “back-end” manipulating the user application running on the CN through a single level fan-out hierarchy running on the ION.
|
Current standard
|
Term applied when an API is not “frozen” on a particular version of a standard, but will be upgraded automatically by Offeror as new specifications are released (e.g., “MPI version 2.0” refers to the standard in effect at the time of writing this document, while “current version of MPI” refers to further versions that take effect during the lifetime of this contract.
|
Fully supported
(as applied to system software and tools)
|
A product-quality implementation, documented and maintained by the HPC machine supplier or an affiliated software supplier.
|
Job
|
An allocation of resources to a user for a specified period of time. The user should be given control over which resources can be allocated to a job.
|
Job step
|
A set of (possibly parallel) tasks launched concurrently and able to communicate using a high-speed interconnect. A job typically executes one or more job steps sequentially and/or concurrently. A job step may use any or all of the resources allocated to the job. The user should be given control over which resources are used by a job step.
|
LWK
|
Light-Weight Kernel providing operating system functions to user applications running on CN.
|
Moab
|
Cluster Resources batch scheduler (www.cluserresources.com)
|
OFED
|
Open Fabrics Enterprise Edition (OFED) (http://www.openfabrics.org/)
|
OS
|
Operating System
|
Process
|
A process is an executing (i.e., running) instance of a program. Processes are also frequently referred to as tasks or MPI tasks. Processes are dynamic entities scheduled and controlled by the Operating System that are constantly changing as their machine code instructions are executed by the CPU. Each process consists of (1) system resources that are allocated to it, (2) a section of memory, (3) security attributes (such as its owner and its set of permissions) and (4) the processor state. The processor state includes the contents of its registers and physical memory addresses. Registers are a very small amount of very fast memory that is built into a processor in order to speed up its operations by providing quick access to commonly used values. Processes may have one or more operating system threads associated with it. See: http://www.linfo.org/process.html
|
Published
(as applied to APIs):
|
Where an API is not required to be consistent across platforms, the capability lists it as “published,” referring to the fact that it will be documented and supported, although it will be Offeror- or even platform-specific.
|
RPCTI
|
Remote process control code development tools interface that allows code development tools to interface from the LN through the LUOS on the ION to the LWK on the CN and operate on user processes and threads on the CN.
|
Single-point control
(as applied to tool interfaces)
|
Refers to the ability to control or acquire information on all processes/PEs using a single command or operation.
|
SLURM
|
Simple Linux Resource Management (SLURM) is an Open Source cluster resource management system and parallel application job launch facility. (www.llnl.gov/linux/slurm)
|
Standard
(as applied to APIs)
|
Where an API is required to be consistent across platforms, the reference standard is named as part of the capability. The implementation will include all routines defined by that standard (even if some simply result in no-ops on a given platform).
|
Task
|
A process launched as a job step component, typically an MPI task.
|
Thread
|
A portion of a program that can run independently of and concurrently with other portions of the program. Operating system threads are schedule by the OS. User space threads are scheduled by the runtime system in user space and don’t require intervention of the OS. Threads within a process share the same memory address space. However, each thread has its own set of architectural registers, stack, heap, and instruction counter or pointer and executes instructions independently of other threads.
|
XXX-compatible
(as applied to system software and tool definitions)
|
Requires that a capability be compatible, at the interface level, with the referenced standard, although the lower-level implementation details will differ substantially (e.g., “NFSv4-compatible” means that the distributed file system will be capable of handling standard NFSv4 requests, but need not conform to NFSv4 implementation specifics).
|
