You are on page 1of 35

|  


  
|    


  
Marlon Pierce
Contributions: Ahmet Sayar, Galip Aydin, Mehmet
Aktas, Harshawardhan Gadgil
Community Grids Lab
Indiana University
    
¢ Ôhe real work was done by (in alphabetical
order).
0 Mehmet Aktas
0 Galip Aydin
0 Harshawardhan Gadgil
0 Ahmet Sayar
¢ Project web site:
0 www.crisisgrid.org
¢ Ôhis work was supported by NASA AISÔ as part
of ³SERVOGrid: Complexity Computational
Environment´
 
  |    


  
¢ Pattern Informatics
0 Earthquake forecasting code developed by Prof. John Rundle (UC Davis) and
collaborators.
0 Uses seismic archives.
¢ Regularized Dynamic Annealing Hidden Markov Method (RDAHMM)
0 Ôime series analysis code by Dr. Robert Granat (JPL).
0 Can be applied to GPS and seismic archives.
0 Can be applied to real-time data.
¢ Interdependent Energy Infrastructure Simulation System (IEISS)
¢ GeoFESÔ
0 Finite element method code developed by Dr. Jay Parker (JPL) and Prof. Greg
Lyzenga (JPL/Harvey Mudd College)
0 Uses fault models as input.
¢ Virtual California
0 Prof. Rundle¶s UC-Davis group
0 Used for forecasting
0 Uses fault and fault friction input
| 
¢ Îe decided that the Data Grid components of SERVO is best implemented
using standard GIS services.
0 Use Open Geospatial Consortium standards
0 Provide downloadable GIS software to the community as a side effect of SERVO
research.
¢ Îe implemented two cornerstone standards as Îeb Services (ÎS-I+
approach)
0 Îeb Feature Service (ÎFS): data service for storing abstract map features
¢ Supports queries
¢ Faults, GPS, seismic records
0 Îeb Map Service (ÎMS): generate interactive maps from ÎFS¶s and other
ÎMS¶s.
¢ Can be used to set up problems by extracting features (faults, seismic events,
etc) from user GUIs to drive problems such as the PI code and (in near future)
GeoFESÔ, VC.
¢ Îe also built a GIS compatible UDDI and ÎS-Context
0 Browse capabilities files.
¢ Îe are currently working on these steps
0 Improving ÎFS performance
0 Integrating ÎMS with video streaming technologies.
0 Implementing Sensor Îeb Enablement for streaming, real-time data.
   
|   
 |   |
¢ PI is a technique developed at University of California, Davis for
analyzing earthquake seismic records to forecast regions with
high future seismic activity.
0 Ôhey have correctly forecasted the locations of 15 of last 16
earthquakes with magnitude > 5.0 in California.
¢ See Ôiampo, K. F., Rundle, J. B., McGinnis, S. A., & Klein, Î.
Pattern dynamics and forecast methods in seismically active
regions. Pure Ap. Geophys. 159, 2429-2467 (2002).
0 http://citebase.eprints.org/cgi-
bin/fulltext?format=application/pdf&identifier=oai%3AarXiv.org%
3Acond-mat%2F0102032
¢ PI is being applied other regions of the world, and John has
gotten a lot of press.
0 Google ³John Rundle UC Davis Pattern Informatics´
 |       
¢ PI in a Grid environment:
0 Hotspot forecasts are made using publicly available seismic records.
¢ Southern California Earthquake Data Center
¢ Advanced National Seismic System (ANSS) catalogs
0 Code location is unimportant, can be a service through remote execution
0 Results need to be stored, shared, modified
0 Grid/Îeb Services can provide these capabilities
¢ Problems:
0 How do we provide programming interfaces (not just user interfaces) to the above
catalogs?
0 How do we connect remote data sources directly to the PI code.
0 How do we automate this for the entire planet?
¢ Solutions:
0 Use GIS services to provide the input data, plot the output data
¢ Îeb Feature Service for data archives
¢ Îeb Map Service for generating maps
0 Use HPSearch tool to tie together and manage the distributed data sources and
code.
Î
Î
!"

 
 
Î

 

` 

Î Î  

Î 

 

Î 

  
 Î

 
|!     
¢ Ôhe web features are served up by a Îeb Feature Service.
¢ Îeb Map Service aggregates maps
0 NASA OnEarth + our own renderings.
¢ Îe re-implement Open Geospatial Consortium standards using Îeb
Service Standards.
0 SOAP messages, ÎSDL service definitions.
0 Îill allow us to separate messages from HÔÔP transport layer in future.
¢ More ÎMS Info:
0 http://grids.ucs.indiana.edu/ptliupages/publications/acm-gis-sayar.pdf.
0 http://grids.ucs.indiana.edu/ptliupages/publications/Geoinformatics05_asayar.pd
f.
¢ More ÎFS Info:
0 http://grids.ucs.indiana.edu/ptliupages/publications/gwpap243.pdf
¢ More general info, software, demos: http://www.crisisgrid.org
Ô | Ô  "#
¢ HPSearch is an engine for orchestrating distributed Îeb Service
interactions
0 It uses an event system and supports both file transfers and data
streams.
0 Legacy name

¢ HPSearch flows can be scripted with JavaScript


0 HPSearch engine binds the flow to a particular set of remote
services and executes the script.
¢ HPSearch engines are Îeb Services, can be distributed
interoperate for load balancing.
0 Boss/Îorker model

¢ ProxyÎebService: a wrapper class that adds notification and


streaming support to a Îeb Service.
¢ More info: http://www.hpsearch.org



 
  /

"#
 !ë# 
ë  ÎFS
ë
 
$
%&'&(
)
!
ÎMS * '  

 

HPSearch Data Filter


ë 
ë

Virtual
"-  
Data
 0
flow
ë)  1
 


  
 
 !  
 
PI Code Runner
ë 
HPSearch 0 Accumulate Data
ë  0 Run PI Code
0 Create Graph
0 Convert RAÎ -> GML

GML
ë 
   '
.* 
 "     *$%
-* *
+  , 
!"-
 
| || 
| 

 

 


||

¢ IEISS simulates power outages resulting from


damage to electrical and natural gas grids.
¢ GIS Grid integration is similar to earlier PI
application.
¢ Primary differences:
0 Better support for dynamic GIS service discovery.
0 Better integration of distributed state monitoring
(ÎS-Context).
0 Google map clients as well as modified PI clients.

!  Î  " " (   !""    
&%.'' Î!"  //  

Î Î!" #$Î%#$& '#$Î
`Î`
 Î`   
)*+'!*Î
 , *- 
Î #$Î%
 "/ 0Î!"   1./"1 
)  %"-,''% ( 
Î%#$
! 2 %

Î!" ) "- ,


 %% 0''      
| ||| 
''  '
 /" %.á  " %   
/" ( /
/  %''  
   | | 
   0 ! 2 
% /""  1./"1  Î!"

5#67# Î #  " ''  (   !"" 
m3 %  / 0Î!" .4   
  +  6^  
Î # / '' · % 
  % ( /" %    %"-0
 !"  "- 1" 

$%  &


    
||
'
$ ()
1. ÎFS and ÎMS publish their ÎSDL URL to the UDDI Registry.
2. User starts the ÎMS Client on a web browser; the ÎMS Client displays the
available features. User submits a request to the ÎMS Server by selecting
desired features and an area on the map.
3. ÎMS Server dynamically discovers available ÎFSs that provide requested
features through UDDI Registry and obtains their physical locations (ÎSDL
address).
4. ÎMS Server forwards user¶s request to the ÎFS.
5. ÎFS decodes the request, queries the database for the features and
receives the response.
6. ÎFS creates a GML FeatureCollection document from the database
response and publishes this document to NaradaBrokering topic
6  ; ÎMS Server and IEISS receive this GML document.
ÎMS Server creates a map overlay from the received GML document and
sends it to ÎMS Client which in turn displays it to the user.
After receiving the GML document IEISS NB Subscriber invokes


 tool; this tool converts GML to XML Model format to be
processed by IEISS
||
  
7. User invokes IEISS through ÎMS Client interface for the obtained geospatial
features, and ÎMS Client starts a workflow session in the Context Service. On
receiving invocation message, IEISS updates the shared state data for the
workflow session to be ³| |||PROGR ´ on the Context Service. Both
IEISS and ÎMS Client communicate with Context Service via asynchronous
function calls by utilizing Context Respond Handler Service. IEISS runs and
produces an ESRI Shape file that has the outage areas for the given region.
8. IEISS invokes á 
tool to convert produced Shape file to GML format [Fig.3].
After the conversion IEISS updates shared session state to be
³| |OMPL  . As the state changes, the Context Service notifies all
interested workflow entities such as ÎMS Client. Ôo notify ÎMS-Client, the
Context Service publishes the updates to a NB topic
(     áá á) from which the ÎMS-Client receives
notifications.
9. ÎMS makes a request to the ÎFS-L for the IEISS output.
10. ÎFS-L publishes the IEISS output as a GML FeatureCollection document to NB
topic 6  .
ÎMS Server is subscribed to this topic and receives the GML file then converts it
to map overlay,
11. ÎMS Client displays the new model on the map.
 

ðoom-in

ðoom-out

FeatureInfo mode

Measure distance mode

Clear Distance

Drag and Drop mode

Refresh to initial map



 |

¢ ü sic eps:
0 elec ergy Power
A  ur l G s  

Up
e L yer Lis
re
ere
o he m p
0 lick o ³Overl y
Ou ge buo
0 ee he ou ge re o
he m p

 ||

¢ ü sic eps:
0 elec ergy Power  

Up
e L yer Lis
re
ere
o he m p
0 lick o ³Overl y Ou ge
buo
0 Use zoom-i m ppi g ool
below o ge s me ou ge
re i more
e il
0 ee he ou ge re o he
m p

 |||

¢ ü sic eps:
0 elec ergy Power

 ur l G s  

Up
e L yer Lis re
ere

o he m p
0 elec . Peersburg from
he ³Are of | eres

rop
ow lis.
0 lick o ³Overl y Ou ge
buo .
0 ee he ou ge re o he
m p
| !"  #!$%
&'"

¢ ü sic eps:
0 elec ergy Power  

Up
e L yer Lis re
ere
o
he m p
0 elec (i) from he m ppi g
ools below.
0 lick o y fe ure
 o
he m p.
0 ee he i form io for
selece
fe ure i pop-up
wi
ow
($!"
| ')

$ 2!

.  '2!


 * Ô




  
*#++"Ô 
   * ' ,-
GPS displacement (3D)
length two years.

Divided automatically
by HMM into 7 classes.

‰e ures:
‡ Dip due to aquifer
drainage (days 120-
250)
‡ Hector Mine
earthquake (day 626)
‡ Noisy period at
end of time series

¢ Complex data with subtle signals is difficult for humans to


analyze, leading to gaps in analysis
¢ HMM segmentation provides an automatic way to focus attention
on the most interesting parts of the time series
Ô * &Ô*#++

¢ A real-time version of RDHAMM could potentially be


used to detect state change events in live data from
a GPS station.
¢ SCIGN maintains 125+ GPS stations, so trivially
parallel RDAHHM clones can monitor state changes
in the entire network.
0 HPSearch can help
¢ But first we must get the data to RDAHMM.
$!  "+Ô 
 
'  
¢ NB is a distributed messaging
software system.
0 http://www.naradabrokering.or
g
¢ NB system virtualizes transport
links between components.
0 Supports ÔCP/IP, parallel
ÔCP/IP, UDP, SSL.
¢ See e.g.
http://grids.ucs.indiana.edu/ptli
upages/publications/AllHands2
005NB-Paper.pdf for trans-
Atlantic parallel tcp/ip timings.
.  
|  '  Ô 
|  ' 
¢ Ôhe previous slide illustrates an initial interface for capturing,
annotating, and storing/replaying video streams.
¢ Still images can be captured and annotated on shared white
board.
¢ Annotations are stored along with rest of system.
     
  |   

¢ Must address performance issues.
0 Related workshop at GGF 15.
0 HÔÔP is not an adequate transport mechanism for moving
data around.
0 XML representations, compression, etc.
¢ Îell established techniques from real-time
collaboration can be applied to sensors
0 Stream archiving and playback, session management,
software multicasting.
0 Applies to both data streams (GPS) and maps (streaming
video).

You might also like