gns-science / eq-fault-geom Goto Github PK

As SRM Team

we want include fault trace polygons for each fault in the opensha XML

so that we can start to include distributed seismicity in opensha

Out of scope - the third layer for feature-based polygons

done when:

• talk to Russ & Matt re report (below) to confirm the rules. Kiran & I think the first 2 (Trace buffer + Surface Projection) will be a good start
• apply these rules to generate CFM (latest) fault trace polygons into opensha XML format

As SRM Team

When we extract data fom CFM for opensha , we want a stable integer ID to identify the XML fault sections,

so that our downstream tests in GNSScience/nshm-nz-opensha are not disrupted by minor changes e.g filtering out the TVZ faults.

SRM Team

we want to use paraview and other VTK compatible visualising tools

so that we can explore fault geometries as defined in the CFM crustal 2D datasets where each fault section is expected to be a rectangular plane with an upper depth of 0km.

NB VTK has many file representations. For this we want legacy (non-XML) in ASCII mode so it's human readable. eg file header like this one ....

# vtk DataFile Version 4.2
vtk output
ASCII

See also

• https://lorensen.github.io/VTKExamples/site/VTKFileFormats/#simple-legacy-formats which is out of date, but helpful with some simple examples
• https://www.kitware.com/products/books/VTKUsersGuide.pdf which is c2010 !
• https://github.com/nschloe/meshio/tree/20f2c4b2ec59b74ab6cd9e1de52a600d589452fc/test/meshes/vtk contains vtk examples used in meshio tests. These are the most up to date examples I've found.

Done when

• Q: VTK has many option to describe 3D surfaces. What is most appropriate for this feature? e.g pairs
  of triangles will be easily handles by ipyvolume, and flat quadrilaterals are eaily converted to these.
• add a script to extract geometry from the 2D CFM (shapefiles) and export as VTK (legacy, ASCII)
• script should extract one VTK file per fault section

As per crustal version, but for the Hikurangi

As NSHM NZ opensha users

we want to extract fault sections from CFM for NZ crustal faults

so that we can perform SHA usng opensha/open-quake and similar

NB now we do this from the CFM shapefile which includes surface fault traces, dip and depth values. This should produce simliar results but wit the 3D t2urf data as input.

Data set from Laura geodetic deformation.

As python user, I want the package to be installable using setup-tools/pip for ease of use:

• determine best-practice guidelines to follow (setup.py standard pythonic approach)
• pip, virtualenv
• requirements.txt (pip freeze)
• run tests (w nosetests)
• update README.md with getting started

IN our team code review last week (ref #37) we identified that there may be some duplicated code in places where we manipulate and transform geometries etc.

This ticket is for Charles & Andy who are the main authors of these functions to do a more detailed review over these modules to see if there's some simplification of the codebase available.

If so, we can create specific issues for the code refactoring task(s)

There's concern that the edge (see below) in the (esp the 30km) tiled subsections is more ragged than it could be. Is it possible that the filtering mechanism used is somehow exagerrating the raggedness of the western edge?

SRM team have asked for a version of the subduction zone that has a northernmost cutoff at the intersection with the Louiseville Ridge. please produce n 10km and 30km tiles with same slip rate as before.

provide feature test coverage for:

• expected validations (warnings) are triggered
• XML export feature

SRM team needs new opensha Fault Model XML from CFM with the following requirements

• use v1.0 of CFM (previously used CFM 0.9)
• set aveLowerDepth attribute from the CFM Depth_Dfc instead of Depth_D90 field, and applying a scalar...
  • one version is scaled by 0.8
  • one version is scaled by 0.66
• As per previous runs, one version including for ALL NZ fault and one with the low rate TVZ faults removed (however this is done).

Done Criteria

There should be a total of four new XML fault models named:

• cfm_1_0_dfc0_66_all.xml
• cfm_1_0_dfc0_66_no_tvz.xml
• cfm_1_0_dfc0_80_all.xml
• cfm_1_0_dfc0_80_no_tvz.xml

using create_stirling_vtk produces exception

NameError                                 Traceback (most recent call last)
<ipython-input-5-f7049921745c> in <module>
     11 for i, fault in sorted_wgs.iterrows():
     12     nztm_geometry_i = faults.iloc[i].geometry
---> 13     cv.create_stirling_vtk(fault, section_id=i, nztm_geometry=nztm_geometry_i)

~/anaconda3/envs/ipyvolume/lib/python3.8/site-packages/eq_fault_geom/geomio/cfm_shp_to_vtk.py in create_stirling_vtk(fault_info, section_id, nztm_geometry)
    176         file_name = "".join(file_list)
    177     file_path = Path(file_name)
--> 178     output_file = Path.joinpath(output_path, file_path).with_suffix(vtk_suffix)
    179     meshio.write(output_file, mesh, file_format="vtk", binary=False)
    180 

NameError: name 'vtk_suffix' is not defined

We we have just discovered the opensha rupture building chokes on Longitudes < 0 if they result in a 3D surface crossing the dateline.

The two new Kermadec trench sections in CFM 0.9 both fail because of this. e.g.

@voj has tested and can avoid this if we simply add 360 to any longitudes less than 0 (and there are many like this).

Our eq-fault_geom scripts should do this so we don't need to modify the upstream project.

As SRM team,

we want the larger hikurangi geometry available

so we can produce new rupture sets.

As SRM team we want to extract relevant data from shapefile and write it in a format that OpenSHA can read.

• Read in CFM source parameters from shapefile
• Implement checks of parameters.
• Write script to write out data in XML format.

from review #37

/eq_fault_geom/faultmeshio/cfm_shape_to_*.py are command scripts

these should:

• be migrated to the CLI folder
• use optparse package (or similar) to implement a simple Command Line Interface for the user
• remove any any hard-coded paths or files in the script
• have a simple --help option telling the user how to use it.

Points should be written along strike in an order so that the dip direction is 90 degrees RIGHT of thw way that points are written (e.g. points should be written N to S for a W-dipping fault).

Testing CFM XML in opensha has revealed this input raises an error in opensha

<i124 sectionId="124" sectionName="Fiordland" aveLongTermSlipRate="9.0" slipRateStDev="5.5" aveDip="25.0" aveRake="90.0" aveUpperDepth="0.0" aveLowerDepth="0.0" aseismicSlipFactor="0.0" couplingCoeff="1.0" dipDirection="131.5" parentSectionId="-1" connector="false">

In these cases the CFM XML extract should skip these elements and issue a warning message so the user know that data is missing.

NB to workaround this I've set a positive value for aveLowerDepth.

@sapikara pls add test coverage for this case

As SRM Team,

We want to exclude the Taupo Volcanic Zone (TVZ) faults from opensha data sets

So that we can assess their impact on rupture set size

Done when:

• NB region polygon is easily defined (e.g. a WKT string)
• fault traces whose points are entirely within the region are excluded from output dataset
• provide a CLI interface allowing for option parsing for
  • input path
  • output path
  • exclude region spec(s) as WKT string
  • anything else ?

SRM team needs new opensha Fault Model XML from CFM with the following requirements

• use v1.0 of CFM
• set aveLowerDepth attribute from the CFM Depth_Dfc
• set new domainNo and domainName fields from CFM on each fault element
• As per previous runs, one version including for ALL NZ fault and one with the low rate TVZ faults removed (however this is done).

Done Criteria

There should be a total of two new XML fault models named:

• cfm_1_0_domain_all.xml
• cfm_1_0_domain_no_tvz.xml

As SRM Team

we want to know if we need to massage the fault intersection for fault zone polygons

So lets take a look at what UCERF3 have done.

I've uploaded data here https://nshmrevisionproject.slack.com/archives/C019L824D99/p1612205551002500

/eq_fault_geom/geomio/run_cfm_param_checks.py needs to

• be moved into ../cli package
• use optparse package (or similar) to implement a simple Command Line Interface for the user
• remove any any hard-coded paths or files in the script
• provide a --help option telling the user how to use it.

package trawl....

• /testing (deprecate bye bye!
• /data add a README .... this is not 'real world' data folks
• /apps to migrate into eq-fault-geom/cli
• /eq_fault_geom/faultmeshio
  • init.py - check use of *** / setup style variable here.
  • cfm_shape_to_*.py are CLI modules for above
  • tsurf.py extends meshio to add tsurf support read/write
• eq_fault_geom/faultmeshops/trace_to_mesh.py convertng CFM shapefile to tri or quad fault surfaces (juptyter viz)
• /eq_fault_geom/geomio/
  • array_operations.py utils for GMT and GeoTiff (the grids)
  • buffer_example.py eg for chris
  • cfm_faults.py the CFM => opensha XML module
  • manipulate_interface_geom.sh builds the GeoTIFF of hikurangi from the GMT grid file
  • read_cfm_shp.py can be killed
  • run_cfm_param_checks.py to be migrated into ../cli (CLI for cfm_fault.py)
• /eq_fault_geom/geomops/rupture_set/ Chris hikurangi rupture generation demo
  • subduction_interface buld hikurangi csv tiles from rhe GeoTiff

@andy22b I found the CFM XML contains the following elements which look supspiciously like subduction data.

Can you help us figure out if they're considered Crustal or not? & If NOT, then we need a feature that can filter these out.

Hikurangi

(eq-fault-geom) chrisbc@tryharder-ubuntu:~/DEV/GNS/eq-fault-geom/src$>grep Hikurangi NZ_CFM_V0.3_crustal_opensha.xml
    <i152 sectionId="152" sectionName="Hikurangi Hawke Bay" aveLongTermSlipRate="44.0" slipRateStDev="3.0" aveDip="0.0" aveRake="90.0" aveUpperDepth="0.0" aveLowerDepth="20.0" aseismicSlipFactor="0.0" couplingCoeff="1.0" dipDirection="296.8" parentSectionId="-1" connector="false">
      <FaultTrace name="Hikurangi Hawke Bay">
    <i153 sectionId="153" sectionName="Hikurangi Raukumara" aveLongTermSlipRate="54.0" slipRateStDev="6.0" aveDip="0.0" aveRake="90.0" aveUpperDepth="0.0" aveLowerDepth="20.0" aseismicSlipFactor="0.0" couplingCoeff="1.0" dipDirection="301.4" parentSectionId="-1" connector="false">
      <FaultTrace name="Hikurangi Raukumara">
    <i154 sectionId="154" sectionName="Hikurangi Wellington" aveLongTermSlipRate="25.0" slipRateStDev="5.0" aveDip="0.0" aveRake="90.0" aveUpperDepth="0.0" aveLowerDepth="30.0" aseismicSlipFactor="0.0" couplingCoeff="1.0" dipDirection="336.4" parentSectionId="-1" connector="false">
      <FaultTrace name="Hikurangi Wellington">

Puysegur

(eq-fault-geom) chrisbc@tryharder-ubuntu:~/DEV/GNS/eq-fault-geom/src$ grep Puys NZ_CFM_V0.3_crustal_opensha.xml 
    <i431 sectionId="431" sectionName="Puysegur" aveLongTermSlipRate="27.0" slipRateStDev="9.0" aveDip="20.0" aveRake="115.0" aveUpperDepth="0.0" aveLowerDepth="15.0" aseismicSlipFactor="0.0" couplingCoeff="1.0" dipDirection="101.3" parentSectionId="-1" connector="false">
      <FaultTrace name="Puysegur">
    <i432 sectionId="432" sectionName="Puysegur Ridge" aveLongTermSlipRate="14.0" slipRateStDev="14.0" aveDip="85.0" aveRake="180.0" aveUpperDepth="0.0" aveLowerDepth="12.0" aseismicSlipFactor="0.0" couplingCoeff="1.0" dipDirection="107.8" parentSectionId="-1" connector="false">
      <FaultTrace name="Puysegur Ridge">

So we can move ahead with new analysis

Done when:

• identify latest version (is it 0.9 or 1.0??)
• Update TVZ exclusion rules as per Russ Van Dissum advice
• check name of slipRateStdDev in XML (note the two ds)
• produce a new crustal XML (complete)
• produce a new crustal XML (Sans TVZ)