1. Interacting Data Services for Distributed Earthquake Modeling Marlon Pierce, Choonhan Youn, and Geoffrey Fox Community Grids Lab Indiana University

2. Overview Basic Web services and architecture of the GEM computational web portal. Requirements for enabling code interoperability: data models and services GEM data models Manipulating data: data service interfaces and inheritance organization. Plugging services into the architecture.

4. GEM Portlets and Portal Stacks User interfaces to GEM services (Code Submission, Job Monitoring, File Management for Host X) are all managed as portlets. Users, administrators can customize their portal interfaces to just precisely the services they want. Core Grid Services User facing Web Service Ports Application Grid Web Services Aggregation Portals Message Security, Information Services

6. Client Stubs DB Service 1 JDBC DB Job Sub/Mon And File Services Operating and Queuing Systems User Interface (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)(13) (14) Visualization Service RIVA (15) (16) (17) (18) (19) Host 1Host 2Host 3

7. Jetspeed Computing Portal: Choose Portlets 4 available portlets linking to Web Services I choose two

8. Choose Portlet Layout Choose 1-column Layout Original 2-column Layout

9. Lists user files on selected host, noahsark. File operations include Upload, download, Copy, rename, crossload Tabs indicate available portlet interfaces. File management

11. GEM Computing Portal A number of simulation methods for studying earthquakes are being developed by GEM consortium including: –Simplex, Disloc, GeoFEST (JPL) –Virtual California (UC-Davis) –PARK codes (Brown) As codes become more widely used, problems emerge: –Need to manage information about distributed data sources: multiple databases, sensors, simulated data. –Need to organize, manage information about multiple code installation sites. –Need to simplify access to data, use of codes, and use of visualization/analysis tools for broad range of users –Need to support metadata information such as job archives, validation, benchmark information, etc.

12. XML Schemas for Code I/O Many existing applications with overlapping or complementary capabilities –Disloc calculates surface displacements based on arbitrary dipping dislocations in an elastic half plane. –Simplex inverts surface displacements to calculate fault parameters –GeoFEST is a 3D visco-elastic finite element code. –Virtual California simulates interactions between vertical strike- slip faults. –PARK is a boundary element code that calculates fault slip velocity history based on fault frictional properties. Relationships shown in next figure

13. Code Linkages in Initial System Elastic Dislocation Pattern Recognizers Fault Model BEM Viscoelastic Layered BEM Viscoelastic FEM Elastic Dislocation Inversion

14. Motivating Scenario: Value of Multiple Satellite Look Angles InSAR satellite data can be used to improve the error estimates of model fault parameters (i.e. calculations of Simplex) How much improvement do you get with additional calculations? Use Disloc to generate synthetic data Donnellan, A., et al: Final Report on the GESS Study— Inversion of Earthquake Fault Parameters Using Multiple Look Angles.

15. Where to Start? Disloc and Simplex have a relatively obvious interaction, complementary capabilities. Our solution is to minimize changes to codes. –Simplicity, extensibility exchanged for performance and tight integration. –Provide wrappers

18. Problems Codes all use “legacy” text formats for describing input and output. Input and output data often combined with code-specific information. –Number of iterations Data not always represented uniformly Larger issues: –We must enable distributed code integration through data flow. –Data transfer performance is not the key issue… –But ‘workflow’ is –And metadata management is.

19. Solutions We need the following: –Data models –Programming interfaces to data –Interfaces themselves need structural organization –Implementations of the interfaces –Integration of the interfaces and implementations into our service architecture. The structural organization should allow extension to specific applications –Anticipating integration of VC, PARK, GeoFEST, etc. We will use WSDL and SOAP for interface description and protocol implementation. –WSDL defines service APIs in XML Implementations are in Java, although nothing is language specific.

20. Fault Data Model Schema

21. Sample Fault Schema Pieces

22. Fault Data Schema Pieces II

23. Fault Data Schema Pieces III

24. Service Interface Structure FaultData 1.GetFaults 2.SetFaults DisplaceData 1.GetDisplace 2.SetDisplace DislocData GEMCode 1.Import 2.Export

25. FaultData Interface Methods Now that we have data models, need to define some interface methods for manipulating them. Fault data schemas and instances may be freely translated between Java and XML (Castor) Interface expressed in Java for brevity but actually WSDL public interface FaultData { public Fault[] getAllFaults(); public Fault getFault(String faultName); public void setFault(Fault sampleFault, String faultName); }

26. GEM Code Superclass Encapsulates methods for specific proxy wrappers. Specific code wrappers extend this class –Disloc, Simplex wrappers, for example Import and export methods are used to translate between the legacy code formats and the wrapper. public abstract class GEMCode { pubic abstract void exportInputData(File f, GEMCode gc); public abstract GEMCode importInputData(File filename); public abstract void exportOutputData(File f, GEMCode gc); public abstract GEMCode importOutputData(File filename); }

27. Disloc Data Service Interface Finally, the specific code data service must extend the above interfaces and superclasses, implementing the required methods. public class DislocData extends GEMCode implements FaultData, DisplaceData { … public void createInputFile() { ; } public void setObservationStyle(String obsvStyle) { ; } public void setGridObsvPoints(XSpan x, YSpan y) { ; } public void setFreeObsvPoints(PointSpec[] points) { ; } }

28. Interacting Data Services We have previously described data models and data service implementations. We now describe how these interact with other services to create, archive, and exchange data.

29. Browser Interface User Interface Server User selects codes, resources, and code data. HTTP Disloc Data Service Disloc Execution Service SOAP/HTTP User requests translated to XML data formats using the remote service. Input data exported to legacy format and transferred to execution host. Legacy output transferred back to data service and imported back into XML formats.

30. User Interface Server Simplex Data Service Disloc Data Service (1) Requests formatted Disloc output data be pushed to Data Hub. Data Hub Service (2) XML displacement data is transferred. (4) Requests and receives displacement data. (3) Signals Simplex to request displacement data from Data Hub. Execution Host Execution Host