Beta-turns are important topological motifs for biological recognition of proteins and peptides. Organic molecules that sample the side chain positions of beta-turns have shown broad binding capacity to multiple different receptors, for example benzodiazepines. Beta-turns have traditionally been classified into various types based on the backbone dihedral angles (phi2, psi2, phi3 and psi3). Indeed, 57-68% of beta-turns are currently classified into 8 different backbone families (Type I, Type II, Type I', Type II', Type VIII, Type VIa1, Type VIa2 and Type VIb and Type IV which represents unclassified beta-turns). Although this classification of beta-turns has been useful, the resulting beta-turn types are not ideal for the design of beta-turn mimetics as they do not reflect topological features of the recognition elements, the side chains. To overcome this, we have extracted beta-turns from a data set of non-homologous and high-resolution protein crystal structures. The side chain positions, as defined by C(alpha)-C(beta) vectors, of these turns have been clustered using the kth nearest neighbor clustering and filtered nearest centroid sorting algorithms. Nine clusters were obtained that cluster 90% of the data, and the average intra-cluster RMSD of the four C(alpha)-C(beta) vectors is 0.36. The nine clusters therefore represent the topology of the side chain scaffold architecture of the vast majority of beta-turns. The mean structures of the nine clusters are useful for the development of beta-turn mimetics and as biological descriptors for focusing combinatorial chemistry towards biologically relevant topological space.

No abstract

Cloud computing is currently based on hardware virtualization wherein a host operating system provides a virtual machine interface nearly identical to that of physical hardware to guest operating systems. Full transparency allows backward compatibility with legacy software but introduces unpredictability at the guest operating system (OS) level. The time perceived by the guest OS is non-linear. As a consequence, it is difficult to run real-time or latency-sensitive applications in the cloud. In this paper we describe an alternative approach to cloud computing where we run all user applications on top of a single cloud operating system called Osprey. Osprey allows dependable, predictable, and real-time computing by consistently managing all system resources and exporting relevant information to the applications. Osprey ensures compatibility with legacy software through OS emulation provided by libraries and by porting runtime environments. Osprey's resource containers fully specify constraints between applications to enforce full application isolation for real-time execution guarantees. Osprey pushes much of the state out of the kernel into user applications for several benefits: full application accounting, mobility support, and efficient networking. Using a kernel-based packet filter, Osprey dispatches incoming packets to the user application as quickly as possible, eliminating the kernel from the critical path. A real-time scheduler then decides on the priority and order in which applications process their incoming packets while maintaining the limits set forth in the resource container. We have implemented a mostly complete Osprey prototype for the x86 architecture and we plan to port it to ARM and PowerPC and to develop a Linux library OS.

In this paper we discuss our experiences in bringing Plan 9 to the IBM Blue Gene series supercomputers. We describe our research goals in doing the work; the effort needed for the port; some of the unique aspects of Plan 9 and their application to BG/P networks; an MPI-like library we have developed for native Plan 9 programs on Blue Gene; and, finally, a binary compatibility environment which can run Blue Gene Compute Node Kernel programs. We are currently working on bringing up the Linpack benchmark, with the goal of gaining a place for Plan 9 on the Top 500 list.

Within a few short years, we can expect to be dealing with multi-million-thread programs running on million-core systems [16]. This will no doubt stress the contemporary HPC software model which was developed in a time when 512 cores was a large number. Historical approaches have been further challenged by the increased desire of developers and end users for supercomputer light weight kernels (LWKs) to support the same environment, libraries, and tools as their desktops. As a result, the emerging workloads of today are far more sophisticated than those of the last two decades when much of the HPC infrastructure was developed, and feature the use of scripting environments such as Python, dynamic libraries, and complex multi-scale physics frameworks. Complicating this picture is the overwhelming management, monitoring and reliability problem created by the huge number of nodes in a system of that magnitude.We believe that a re-evaluation and exploration of distributed system principals is called for in order to address the challenges of ultrascale. To that end we will be evaluating and extending the Plan 9 [21] distributed system on the largest machines available to us, namely the BG/L [28] and BG/P [10] supercomputers. We have chosen Plan 9 based on our previous experiences with it in combination with previous research [17] which determined Plan 9 was a "right weight kernel", balancing trade offs between LWKs and more general purpose operating systems such as Linux. To deal with issues of scale, we plan on leveraging the use of the highperformance interconnects by system services as well as exploring aggregation as more of a first-class system construct -providing dynamic hierarchical organization and management of all resources. Our plan is to evaluate the viability of these concepts at scale as well as create an alternative development and execution environment which compliments the features and capabilities of the existing system software and run time options. Our intent is to broaden the application base as well as make the system as a whole more approachable to a larger class of developers and end-users.