Central Web-Based Collaboratory

A web-based OSD-CI collaboratory will be the primary point of contact for all participants, as well as the mechanism for studying how people, software, and systems interact. The computer science PIs have extensive experience constructing and deploying production-quality web services to establish the cyberinfrastructure of this collaboratory and will make use of the MogServ system developed by co-PI Madey, which builds upon state-of-the-art open source tools such as Weka, Apache Lucene and Tomcat/Axis. This cyberinfrastructure must support three distinct repositories of interacting data. The design gallery will consist of all the submissions currently under consideration by the community. This venue houses job submissions from end users, archives products delivered by Citizen Engineers in response to these job postings, and solicits feedback upon the results. The social network will represent the properties, qualifications, and actions of all the Citizen Engineers participating in the system.  The network will accept voluntary membership information from the participants, record significant actions taken by the participant within the system, and allow for the discovery of professional relationships between participants. The tool repository will consist of a collection of open source tools (e.g., FEAP, OPENSEES and OPENFOAM and contributed tools from members of the collaboratory, e.g., data archives, real-time data, tele-experiments, simulation/ analysis tools, and e-design aids, with data types and allowable operations.

 

Note that previous attempts to enforce standardized analysis packages on the Civil Engineering community have failed, largely because engineers are unwilling to abandon tools that they trust. As a result, a commercial integrated tool repository does not exist for Civil Engineers, including the current project management paradigm in the industry: Building Information Modeling. Further, the prior attempts to deliver such tools required the imposition of a de-facto analysis standard on the community – an idea the community has soundly rejected. We acknowledge this reality and accommodate it with a hybrid model that includes both open source tools that can be embedded in the system and the capacity to upload information and results obtained from the use of proprietary software whose analyses have been executed locally by a Citizen Engineer outside the portal. This design chain not only circumvents software licensing issues, but more importantly allows the Citizen Engineers to employ trusted software they possess at any stage of their analyses by importing data from and exporting data to the integrated design chain within the cyberinfrastructure. As such, Citizen Engineers will retain ongoing access to the analyses they trust and have access to new collective resources.

 

Unlike existing web-based collaborative tools, most of the heavy lifting will occur outside of the repository itself.  Participants will propose projects, upload data, and select work units, but the real work will take place at the “edge” of the system by humans, computers, or some mix of the two.  Some tasks, such as the detailed peer review of a finalized design, may be assigned to a single expert Citizen Engineer through the collaboratory, but then performed as intellectual detail work on a personal workstation, with the results uploaded to the system.  Other tasks, such as the visual analysis of storm damage to structures, can be “crowd sourced” to large numbers of participants with varying capabilities. Still others, such as the detailed simulation of fluid-structure interactions using computational fluid dynamics and finite element models, will be executed through simulation on large clouds of computers.

 

Dynamic Computing Cloud

Current analysis and design methods, such as nonlinear finite element analyses of complex structures, can overstress the in-house computational capabilities of some firms and laboratories and far exceed those of most Citizen Engineers. While the OSD-CI will provide a small computing resource to bootstrap initial users, this will not be sufficient to serve the entire community.  Fortunately, most civil engineering workloads are CPU-bound parameter sweeps, so they are naturally parallel and can be satisfied by large numbers of conventional computers. So as yet another dimension of sharing, OSD-CI will enable members to contribute their own computing resources to power the needs of the collaboratory. To do so, OSD-CI will leverage the Condor distributed computing system, a major component of the NSF-supported cyberinfrastructure portfolio to which Co-PI Thain significantly contributes.

 

OSD-CI will gain computing resources in several ways.  (1) Academic partners with large Condor installations may configure them to join OSD-CI and accept work from collaborators.  (2) Individuals and smaller sites will be able to download a small package from OSD-CI that will quickly install a custom Condor package that talks directly to OSD-CI without any configuration.  (3) For very large workloads, resources will be allocated through the Amazon Elastic Computing Cloud (EC²), as an in-kind contribution through Amazon Research Grants, or OSD-CI will deploy our Condor package, thus transparently increasing the size of the system. 

 

Multi-Dimensional Policy Enforcement and Evaluation

 

The primary computer science challenge in this multidimensional OSD-CI will be the reconciliation of complex policies necessary to achieve extreme trustworthy social computing. Each dimension of collaboration will have its own set of policies that must be respected in order to gain the trust and the commitment of all of the participants. End users proposing jobs to the design gallery – ranging from tiny crowd-sourced tasks to enormous design projects – must be able to specify who will work on these tasks and how the results will be aggregated and returned. Institutions providing computing resources to the cloud must be able to control how their cycles are allocated and who receives priority under conflicting demands.

 

However, the more challenging problems arise when we consider policies that must stretch across dimensions. An end user submitting a job may reasonably insist that the work be done with a particular version of an open source tool on a particular operating system, so as to have some faith in the reproducibility of results. Simultaneously, an institutional provider of computing resources for the cloud may insist that it only be used for certain tools or projects. Two problems result when we try to reconcile all of these policies together. First, how do we express the policies? The most widely used language in this context is ClassAds, which are used in the paradigm of “matchmaking” for distributed computing.  However, we have found in practice that, like many programming languages, all the features of ClassAds cannot be easily used by non-programmers. Internally, we must use the fully expressive language, because this is necessary for the actual policy execution, so we will explore and evaluate a number of techniques for generating policy automatically, e.g., user specifications from pre-defined selections or sliding scale rankings of preferences. With this information, our algorithms would construct the exact policy, introducing deferred policies when exceptions arise. By creating an intelligent system that informs the process, the occurrence of exceptions will diminish with time. The second concern surrounds troubleshooting of policies, which is much harder with multidimensional policies. To this end, automatic policy analysis tools are required, such as the application of data mining techniques to large scale computing systems using the ClassAd language. These techniques will be extended to multidimensional policies in this proposal, taking advantage of the substantial increase in data to discover/report policy problems.