Assembling So. Nevada Geophysical Data to Model Seismic Response in Las Vegas Valley

1. Assembling So. Nevada Geophysical Datato Model Seismic Responsein Las Vegas Valley John N. Louie & John G. Anderson Seismological Lab, UNR May 2002 - May 2005

2. LVVSR Components @UNR • Model Assembler • Enables LLNL to use existing knowledge • Adding new data; interoperation and archiving • Shallow shear-velocity transects • Extensive reconnaissance data • E3D sensitivity studies • Place facilities and expertise at UNR • Guide model assembly

3. ModelAssembler • A code to stitch together existing regional geophysical and geological data sets. • Generates multi-gigabyte E3D input.

4. Jachens, 1999 GB Classified Geology

5. Regional Basin DepthsJachens and Blakely, USGSSedimentary and VolcanicDerived from Basin Gravity

6. Precedence Rule Model Assembler stitches together Langenheims’s thickness model for the Las Vegas basin, and basin depths estimated by a bedrock proximity rule from a geologic map of the southwestern US. Map views of vertically averaged velocities in the Vp output of MA are made with the JRG tool.

7. Interpolation Rule Minimum Basin Thickness Test ModelAssembler interpolates basin depth data by distance-weighted averaging of all data points within a radius of the grid point. (Here the radius was 1 km.) So bedrock areas within a radius of a basin point can receive small thicknesses. A minimum basin thickness rule controls the area of bedrock after interpolation. There is no effect on proximity basin-depth estimates.

8. Comparison of Regional Basin Estimators Rogers’s March ‘02 5% topographic gradient result is above. Bedrock is blue and basins are yellow. (Only showing surface velocity.) Louie’s July ‘02 ModelAssembler 2.0 result is below. Bedrock is red and basins are green-to-blue. (Showing 20-km vertical velocity average.) The bedrock nature of flat Pahute Mesa is now shown, but some Tertiary sediments like the Funeral Fm. in Death Valley also show as bedrock. LV PM SM DV PM LV SM DV

9. Model Assembler Operation Outline • Documents the methods in MA  An outline in place of a complicated flowchart.  Guidance to users in this color.

10. Model Assembler Operation Outline 1. Self-document and get infile name from command line  Usage: java ModelAssembler file.in > file.out  Run from UNIX command line.  The infile is a control file, in a format identical to that used by E3D, containing additional control lines ignored by E3D. MA reads its additional lines and several E3D control lines.  MA acts as a preprocessor for E3D by helping to set up the E3D control file as well as the multi-Gb grid inputs for E3D. 2. Read infile to a Vector of Strings, one per line  Vector input = ModelAssembler.readInput(infile);  The infile (control file) is simply read into a series of strings, one per line, including all comments and lines for E3D ignored by MA.

11. Model Assembler Operation Outline 3. Parse input Vector to set up grid class with parameters  Grid grid = new Grid(input);  The infile strings are parsed to identify the unique “grid” control line, which sets the geographic location, orientation, and sampling of the 3-d grid.  The translation between lat and lon and grid coordinates uses a flat-earth Cartesian projection accurate only at the midpoint of the grid. Grid axes follow rhumb lines and not great circles. 4. Parse input Vector to set up needed classes and parameters, and read data files, producing ordered precedence Vector of class Fill objects  grid.preced = Fill.setupInput(grid, input);  Parses basin and geotech lines from control file.  Based on order of basin and geotech lines in control file, arranges which detailed data sets will substitute for (take precedence over) regional background data sets, where there is overlap.  Opens and reads the geological data from the files the control lines point to.  Geological data are always georeferenced, and supplied to MA as editable text files with points in any order.

12. Model Assembler Operation Outline 5. Compute basin thickness at all surface points of grid  grid.setupThicks();  Interpolates basin thickness at each surface point of grid from precedence list of basin data sets.  Sorting out closest basin data points for each grid surface point from unordered data vectors is now computationally inefficient (done by brute force) and time consuming.  The interpolation of basin thickness is a distance-weighted average of all basin thickness data points (not geographically superceded) falling within a radius of the grid surface point.  A rule controls when small interpolated thicknesses are considered to be zero.  The search radius for data points is a parameter set for each data set in each basin line in the control file. The radius controls the 3d effect.  Where no data points are within radius, the location is assumed to be bedrock, outside any basin.

13. Model Assembler Operation Outline 6. Compute geotechnical shear velocity at all surface points of grid  grid.setupGeotech();  Interpolates geotechnical shear velocity at each surface point of grid from precedence list of geotech data sets.  The interpolation of geotechnical velocities is a distance-weighted average of all geotechnical data points (not geographically superceded) falling within a radius of the grid surface point.  The search radius for data points is a parameter set for each data set in each geotech line in the control file.  Where no data points are within radius, the NEHRP B-C Boundary 30-m shear velocity of 0.76 km/s is assumed outside basins, and the NEHRP C-D Boundary 30-m shear velocity of 0.35 km/s is assumed inside basins.

14. Model Assembler Operation Outline 7. If requested write Field (2000, 2001) amplifications for all surface points of grid  grid.writeAmplif(input);  Computed directly from interpolated basin thickness and geotechnical velocity. 8. Write binary grid files given precedence Vector  grid.writeGrids();  Interpolates grid depth-point properties from rules programmed for properties versus depth inside and outside basins.  Rules control estimation of other properties from the property set by the rule for a particular geology and depth.  Within basins, a rule sets the density-versus-depth profile (Jachens and Blakely model from oil-well logs in central Nevada); an equation estimates Vp (km/s) from density (g/cc)– {qv = density/0.23; vp = qv*qv*qv*qv*0.3048/1000);}; and Vp/Vs is assumed to be the square root of three to estimate Vs.  Outside and under basins, a rule sets the Vp-versus-depth profile- the profile used by the SGBDSN for earthquake location; an equation (inverse of above) determines density from Vp; and then the same Vp/Vs ratio is applied.  Properties at depths between control-point depths in the rules are linearly interpolated. (more…)

15. Model Assembler Operation Outline 8 (continued). Write binary grid files given precedence Vector  Geotechnical velocities are thickness-weighted and slowness-averaged into the shear velocities of the upper grid zones.  Where basin depths are less than the grid spacing dh, geotechnical, basin, and bedrock velocities are all thickness-weighted and slowness-averaged into the shear velocity of the upper grid zone.  Except in the uppermost zone, to depth dh, there is no averaging across basin boundaries. A grid zone is either all in the basin or it is all in the bedrock.  Given the pre-computed interpolated basin thicknesses and geotechnical velocities, following the profile and equation rules to compute the properties at the grid zone depths is rapid, and writing large grid volumes is not slow. All these operations could be done inside E3D. 9. Write (altered) input file to standard out  ModelAssembler.outputInput(input);  MA writes a new version of the control file for input to E3D, adding translation of lat and lon given for source and sac lines to grid l, m, n coordinates.

16. Illustrate Models with Field (2001) Amplification-Mapping • To visualize 1-10 km basin depths together with shallow geotechnical velocities.

17. How to InterpolateRandomly Spaced Measurements? • ModelAssembler does the gridding of arbitrarily located geological data. • Basin thicknesses and geotechnical velocities. • Data are geo-referenced to points on a map. • MA averages and interpolates among points on a map. • If grid zone contains one or more measurements, average them. • If not, extrapolate from nearby measurements. • Use default properties if no data “nearby.”

18. How to Interpolate Randomly Spaced Measurements? • Assign value of nearest neighbor within search radius

19. How to Interpolate Randomly Spaced Measurements?

20. How to Interpolate Randomly Spaced Measurements? • Distance-weighted average of all within search radius

21. How to Interpolate Randomly Spaced Measurements?

22. How to Interpolate Randomly Spaced Measurements? • Distance-weighted average of closest in each quadrant

23. Average Nearest in Each Quadrant

24. Observations on Interpolations • “Nearness” radius setting has big effect. • Default properties differ sharply from local data. • Nearest-neighbor looks “geological.” • May represent spatial variability, but low confidence in extrapolated values. • Average of all nearby data is too smooth. • Misrepresents spatial variability, but gives high confidence in regional average values. • Used by MA3 for basin thickness and geotechnical data. • Average of nearest data in 4 directions seems more realistic. Still requires making a geologic model. • Retains some of the measured spatial variability. • Extrapolating averages gives higher confidence.

25. Las Vegas Transect Measurements Most of Strip, Downtown; south side of Valley only

26. Las Vegas Transect Measurements V100 echoes V30

27. NSL, July ‘03, sponsored by LLNL Geologic Info to Predict Vs • Can soil maps predict Vs?

28. Does extrapolating Vs work? • Vs assigned to soil-map units using central-City measurements. • Later, outlying measurements (B. Luke, UNLV) not predicted by maps.

29. 2 1 3 4 Does extrapolating Vs work? • Vs assigned to soil-map units using central-City measurements. • Later, outlying measurements (B. Luke, UNLV) not predicted by maps.

30. How to Extrapolate Shallow Vs • Can we simply extrapolate measurements throughout basin? • No, need guidance of a geologic model.

32. LVVSR Components @UNR • Model Assembler 3.6.1 Delivery to LLNL • Incorporates stratigraphic model for LVV • Adjusts regional assumptions to fit LVV data

33. How to Extrapolate Shallow Vs • Correlate 75 Vs measurements against stratigraphic model. • Stratigraphy interpolated between >500 water-well logs.

34. Extrapolated vs. Measured • Comparisons along Cheyenne-to-Tropicana transect.

35. How to Extrapolate Shallow Vs • With subsurface information, prediction is better than with soil map.

36. How to Extrapolate Shallow Vs • Well-log correlations predict measurements at more sites than with soil-map correlations. • Hazard is underestimated at fewer sites.

37. Create Top Zone for E3D Grid • Always average on slowness. • Velocities from top 100 meters of stratigraphic model. • Deeper zones interpolate refraction results. • Revise defaults to match.

38. Integrate LV Results with Region

39. Integrate LV Results with Region

40. Summary • Shallow Shear-Velocity Modeling • Difficult to predict amplification from maps. • Stratigraphic model now predicts measurements, extends throughout urban Valley. • Shallow basin has remarkably constant Vs. • Model Assembler • Interpolates point measurements. • Averages data & models into grid. • Incorporates stratigraphic model for shallow LVV. • Regional assumptions adjusted to match LVV data.

42. New Deployment

43. MA Java-C Conversion Notes • A complete re-design of the C code, with help from Dr. Harris and Jeff Stuart • Uses void pointer and type-casting to implement a single Vector structure that is re-usable for different data types • fewer files and pointers need to be handled

44. Java-C Conversion • For the Vector structure: • Explicit functions to allocate and release memory (for an instance of the structure) were implemented • easier to check for memory leaks • clearer and more coherent code

45. Java-C Conversion • Additional structures also have new() and delete() functions that specifically allocate and release memory • easier to detect memory leaks • Static memory allocation is used as much as possible for the implementation of the various structures • to ease the task of handling memory allocation and release

46. Java-C Conversion • The new implementation is still a direct translation of the original java code. • For example, each “.java” file is converted into a “.h” and a “.c” file.

47. Speed Comparison • Testing with an Intel Pentium 4 machine with sample parameters: • The C code execution finishes in about 3.5 minutes, compared to 4.5 minutes for the original Java code • ~20% performance increase • Much additional optimization still to do

48. - = Result Comparison • Testing on Mac OS10.3, the C conversion generates effectively identical binary output files (i.e., den.flt, vs.flt, vp.flt,) compared to the java code

49. Required MA4 Enhancements • Include regional geophysical grids in MA. • The “grids” will be supplied as property-vs-depth profiles. • Alterations to the geotech operations to average in full profiles instead of the V30 values put in now. • Geotech and regional profiles in Luke’s format. • All averaging and interpolation of Vp and Vs done arithmetically on slowness (inverse velocity, for conservation of travel time). Densities combine arithmetically for conservation of mass. • Approximate completion date: mid-May

50. Other MA4 Enhancements • Optional control from basin, profile, and geotech parameter lines on the type of interpolation used: nearest neighbor, linear, distance-weighted, etc. • expected completion date: before mid April • Precision control by truncation of results to 3 or 4 significant figures, to assure identical output across platforms and compilers • expected completion date: before April