Oct6MEPNotes

From Quakewiki

JPL Oct 4 2006 Meeting Notes

• KU group doing research on glaciers: INSAR, other sensors, modeling, GIS, etc. Should position projects to help each other, point should be to justify INSAR mission.

• InSAR database: has different levels of data products. Level 1, 2, etc. These are images. Geoffrey: make this compatible with NVO. Roy Williams, Caltech is the person to contact.

• Jay: raw data is really raw, must be processed. Must define requirements with local JPL experts like Paul Rosen to do the Insar DB milestone.

• John Rundle, California Hazards Institute: AIST project can serve as a prototype. UCSF interested in real time emergency response within the portal. Focus on all hazards, not just earthquakes, that can effect the state. Try to be a permanent state organization, unlike SCEC, which has to compete for funding at national level, reauthorized 3-5 years.

• GCF: we have worked on county GIS systems in Indiana. Can we do the same for California. Rundle: some legal and privacy issues of GIS data. Lisa: Irvine mostly social sciences. They really need to be dealt with or legal issues will disrupt these efforts. JR: California DHS does have funding to support these kinds of things.

• Tom Jordan is retiring as leader of SCEC, as is John McRaney.

• Comments by Lisa on QuakeTables: QT must be expanded to include all of California, not such the south. Also include all of the significant faults, not just strike-slip faults. Need to integrate with CGS fault database. CGS=california geological survey. They have a fault database. Quaketables originally included some of their data. SCEC developed the community fault model. But their model was very geometrically complicated, but it was not used by other scec codes. Must decide what we want to do about these other models. Must merge with these other efforts. Original plan was only to enter data, not to do this integration work. There is also a rectilinear version of the SCEC CFM fault stuff. Legal requirement: "use best available science."

• Hazard maps: moving away from "expert voting model" to the simulation model (JR).

• Jay: do we just need geometry in QT or do we need historically interesting slip values? For example, SF earthquake in 1906 had 2-8 meter slips. People are interested in simulating these things.

• Dennis: do we want to provide enhanced information views in the portal, to better enable the discovery of information. Jay: look at how people traditionally do research and write papers. This will guide you on what information people actually want. Lisa: USGS has their fault database online. It will provide this information: descriptive component, text output, GIS interface. Need to see what kind of GIS data they have. Issue is how to federate this information.

• We want to treat QT not as a competitor or with USGS and other data, but instead use QT to provide a specialized view of external databases that works with the project codes. Important things are interacting semantically with the data to find stuff, filtering/converting into appropriate models, and use common service interfaces to hide data model differences.

• Steps

  step 0: identify databases.
  step 1: define service interface that can be used for federation.   
  step 2: add semantic layer

• Comments by Walter Brooks:

  - parallelizing VC 
  - have set up portals on columbia before.  Can get the security issues worked out.
  - Security is an ongoing problem, but they have done this with other AIST projects.
  - Have taken realtime sensor web data and have done realtime runs on columbia.  Did this with hurricane data.  Can do this with      insar data as a prototype.
  - Have been embedding graphics and viz in the code and can create mpegs of simulations as they are sent.  Use for steering.  
  - They have Globus installed, use PBS on Columbia, so this should be nice from here.

• GCF: is there international interest in this. iSERVO? Problem is Peter Mora is not responsive recently, and he drives. GCF: it is important to show running VC across the world.

• Comments about open source, open channel, RDAHMM, etc.

• Value in series of high performance web services for processing the insar processing. would benefit the glacier problem as well as quakesim.

• Adaptive mesh refinement and FEM modeling can be applied to ice sheets, glaciers.

• How many GPS stations with real time data? Need to find out which ports are available. SCIGN data from Frank Webb should be found. Is this daily? Paul may have some additional daily sites that are not in my listing.

• PI can be treated as a time series source for RDAHMM. But hard to know if it is useful.

• RI hypothesis: big earthquakes will occur where small earthquakes have previously occurred.

• John's current PI-RI stuff is trivially parallel on both the spatial grid and the time zone. This would be a very good BR job. Digital catalog is online.

• ANSS data base is the source. This is in the WFS. A client to this can make daily pulls. This client is treated as a filter. Need to get James to use this?

• Need to make a version of PI that is automatic--automatically runs PI every day and publishes the forecast map. Put it on a Google Map. Color code corresponds to the PI value. Archive the results. For historical data, also show the actual seismic record. Run this daily on Big Red.