The Penn State RS/6000 SP is a uniquely acquired and operated computing facility. This 143 CPU machine, centrally located and jointly owned, is a result of collaboration between academic departments, research groups, and the central academic computing facility. It is the largest on- campus resource at Penn State for meeting the high performance computing needs. Due to the joint ownership structure of the machine, the job scheduling requirements are significantly different from the usual methods of job processor allocation in distributed memory parallel machines. After several years of adapting different queuing systems, primarily the Distributed Queuing System, to our needs, it became obvious that the conventional scheduling systems did not serve the machine scheduling requirements unique to the Penn State SP. We concluded that a robust and easily configurable system needs to be developed to meet our unique needs. We have drawn inspiration from and modeled our system on EASY. As with EASY, we use the application programming interface of LoadLeveler to implement our scheduler. Our scheduler is named Penn State Condominium Scheduler (PSCS). PSCS does policy implementation and job execution on the machine is done by LoadLeveler. PSCS is written to facilitate easier configuration and administration. It does not have any processor architecture dependence. It is similar to the native scheduler in LoadLeveler in this regard. PSCS has incorporated three unique features: (i) node owner affinity which ensures fairness by allocation based on ownership, (ii) backfilling which ensures efficient utilization of resources, and (iii) affinity for services provided which ensures proper matching of jobs to the processors based on memory, software and other requirements. Jobs from users who own nodes in the SP complex have affinity to those particular processors owned by them. They also have preferences granted to them depending on their ownership level. Once the demand from the node owners is met, the next important goal is to keep the machine as fully occupied with running jobs as possible. This is accomplished by backfilling. This scheduler incorporates these features which are most important to successful implementation of multi-owner, centrally located, heterogeneous computing facilities.

The High Performance Fortran language is a 'standard by consensus', developed by individuals and vendors in the high performance computing industry, to provide a low barrier entry to parallel computing. It promises to be an easier to use development environment for distributed memory computing platforms compared to the programming complexity required by message passing libraries such as PVM and MPI. HPF promises much and is still in its infancy.Since HPF was developed in part based on experiences gained with early parallel Fortran compilers such as Thinking Machines CM Fortran, we decided to test the effectiveness of HPF with today's generation of HPF compilers by porting a complex existing model code originally developed using CM Fortran.The model code that we selected is a hybrid computational aeroacoustics code that solves the 3D, time-dependent Euler equations in the near flow field and uses a moving surface Kirchhoff's formula to predict the far field sound radiating from turbofan engine inlets. The original CM Fortran model code was developed on a Thinking Machines CM5. The extensive production research use of this model, using varying grid sizes, provides excellent benchmarks with which to compare the HPF port.Two HPF compilers were selected in the porting effort -- The Portland Group's (PGI) pghpf and the xlhpf compiler from IBM. IBM's xlhpf does not implement some elements of the HPF subset while PGI's offering provides several full-HPF extensions. porting efforts using each compiler exposed the strengths and weaknesses of each.Porting this complex code exposed many of the growing pains associated with the current generation of compilers.Critical sections of the code will be explained and these critical areas of the conversion effort will be discussed. Where necessary we will demonstrate how different porting strategies affected the performance of the code.Finally we will present how the ported code ran, using a varying number of processors, on an IBM SP2 and an SGI Origin 2000. While the current simple port does not match the speed of a CM-5, we hope further porting efforts and improved compiler technology will enable us to eventually match and then surpass CM-5 performance levels. With the shutdown of the NCSA CM-5 and the eventual removal and failure of the remaining Thinking Machines hardware currently installed, this effort will demonstrate that investments in CM Fortran code need not be abandoned and that new life can be breathed into those dusty decks.