Interacting Data Services for Distributed Earthquake Modeling

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 asportlets. • Users, administrators can customize their portal interfaces to just precisely the services they want. Aggregation Portals User facing Web Service Ports Message Security, Information Services Application Grid Web Services Core Grid Services

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

7. 4 available portletslinking to Web ServicesI choose two Jetspeed Computing Portal: Choose Portlets

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

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

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 Inversion Viscoelastic FEM Viscoelastic Layered BEM Elastic Dislocation Pattern Recognizers Fault Model BEM

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 • GetFaults • SetFaults • DisplaceData • GetDisplace • SetDisplace • GEMCode • Import • Export DislocData

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. User selects codes, resources, and code data. Browser Interface User requests translated to XML data formats using the remote service. HTTP User Interface Server SOAP/HTTP Disloc Data Service Disloc Execution 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 (3) Signals Simplex to request displacement data from Data Hub. (1) Requests formatted Disloc output data be pushed to Data Hub. Simplex Data Service Disloc Data Service Execution Host Execution Host Data Hub Service (2) XML displacement data is transferred. (4) Requests and receives displacement data.