Eugene
| Eugene |
Eugene is a 27 TF IBM Blue Gene/P System operated by the NCCS. Eugene has approximately 45 million processor hours available exclusively for use by ORNL staff and for the promotion of research collaborations between ORNL and its core university partner members : (Duke University, Florida State University, Georgia Institute of Technology, North Carolina State University, University of Virginia, University of Tennessee, Vanderbilt University, and Virginia Polytechnic Institute and State University) .
Eugene consists of 2048 850Mhz IBM quad core 450d PowerPC processors and 2GB of memory per each node. Eugene has a front-end node for user logins and compiling of codes. Users submit their jobs from this front-end node and cannot directly login to a compute node. Eugene has 64 I/O nodes and each submitted job must use at least one I/O node. This means that each job consumes a minimum of 32 nodes per execution.
Notice:
Eugene upgraded to Version 1.0 Release 4.0
Eugene was upgraded to Version 1.0 Release 4.0 on Wednesday, September 09.
Please note the following list of new features taken from IBM’s “Blue Gene/P V1R4M0 Memo To Users” document.
- Multiple application threads per core
- A new environment variable has been introduced that controls the number of application threads that can exist on each core: BG_APPTHREADDEPTH=x where x can be 1, 2, or 3. By default, a value of 1 is used. If a number larger than 3 is specified, the maximum value of 3 is used. Setting this environment variable to a value greater than 1 must be done with an understanding that the Compute Node Kernel does not provide a preemptive thread scheduler.
- Binary Core File Generation
- A new environment variable, BG_COREDUMP_BINARY, was added to allow the creation of a full binary core file. The value supplied to this environment variable specifies the MPI ranks for which a binary core file will be generated rather than a lightweight core file. This type of core file can be used with the GNU Project Debugger (GDB). If this variable is not set, all ranks will generate a lightweight core file. The variable must be set to a comma-separated list of the ranks that will generate a binary core file or “*” (an asterisk) to have all ranks generate a binary core file.
- Building Applications
- When building an application in a cross-compile environment such as Blue Gene/P, build tools like configure and make will sometimes compile and execute small code snippets to identify characteristics of the target platform as part of the build process. If these code snippets are compiled with a cross-compiler and then executed on the build machine instead of the target machine, the program might fail to execute or produce results that do not reflect the target machine. When that happens, the configure will fail or not configure as expected. To avoid this problem, the Blue Gene/P system now provides a way to transparently run Blue Gene/P executables on a Blue Gene/P partition when executed on a Blue Gene/P Front End Node. Configuration of this feature is found in the IBM System Blue Gene Solution: Blue Gene/P System Administration Redbook, SG24-7417. Usage information is provided in the IBM System Blue Gene Solution: Application Development Redbook, SG24-7287.
- Recompiling applications
- It is recommended that applications be recompiled after installing a new release of Blue Gene/P software. By recompiling your application for the new release, you ensure that your application will take advantage of the new features contained within the release.
- /jobs directory added to the I/O node
- Move to GBD 6.6
- GBD was upgraded to 6.6.
Before CIOD starts a job, it creates a directory called /jobs/
