Bug: number of ruptures

[chrisdicaprio]

When filtering ruptures by location/radius we get different answers from the solvis api (as viewed on https://nshm.gns.cri.nz/RuptureMap and sovis running on it's own).

To reproduce: use the Hikurangi FaultSystemSolution

	solvis	rupture explorer
no filter	1645	1645
WLG 10km	88	0
WLG 30km	172	148

Sample code used in solivs to filter:

from pathlib import Path
from solvis import FaultSystemSolution, geometry
from nzshm_common.location.location import location_by_id

fs = "HIK"
area_filter = geometry.circle_polygon(radius_m=30_000, lon=location_by_id("WLG")['longitude'], lat=location_by_id("WLG")['latitude'])
soln_dir = Path('/home/chrisdc/tmp')
soln_path = soln_dir / f'{fs}_fault_system_solution.zip'

soln = FaultSystemSolution.from_archive(soln_path)
ruptures = soln.ruptures_with_rupture_rates
ar = soln.get_ruptures_intersecting(area_filter)
print(len(ar))

[chrisbc]

NSHM query example HIK, WLG, 30km ...

hitting: https://nshm-api.gns.cri.nz/kororaa-app-api/graphql

{"query":"query ComboRuptureMapPageQuery(\n  $first: Int!\n  $after: String\n  $model_id: String!\n  $fault_system: String!\n  $location_ids: [String]!\n  $radius_km: Int!\n  $corupture_fault_names: [String]\n  $minimum_mag: Float\n  $maximum_mag: Float\n  $minimum_rate: Float\n  $maximum_rate: Float\n  $sortby: [SimpleSortRupturesArgs]\n) {\n  textual_content_header: KORORAA_textual_content(index: \"rupture_map_header.md\") {\n    ok\n    content {\n      content_type\n      text\n    }\n  }\n  SOLVIS_locations_by_id(location_ids: $location_ids) {\n    edges {\n      node {\n        location_id\n        name\n        radius_geojson(radius_km: $radius_km, style: {stroke_color: \"royalblue\", stroke_width: 3, stroke_opacity: 1, fill_opacity: 0.01, fill_color: \"royalblue\"})\n        id\n      }\n    }\n  }\n  SOLVIS_filter_rupture_sections(filter: {model_id: $model_id, location_ids: $location_ids, fault_system: $fault_system, corupture_fault_names: $corupture_fault_names, radius_km: $radius_km, minimum_mag: $minimum_mag, maximum_mag: $maximum_mag, minimum_rate: $minimum_rate, maximum_rate: $maximum_rate}) {\n    model_id\n    section_count\n    fault_surfaces(style: {stroke_color: \"silver\", fill_color: \"silver\", fill_opacity: 0.25})\n    fault_traces(color_scale: {name: \"inferno\"}, style: {stroke_width: 5})\n    color_scale(name: \"inferno\") {\n      name\n      min_value\n      max_value\n      color_map {\n        levels\n        hexrgbs\n      }\n    }\n    mfd_histogram {\n      bin_center\n      rate\n      cumulative_rate\n    }\n  }\n  SOLVIS_filter_ruptures(first: $first, after: $after, filter: {model_id: $model_id, fault_system: $fault_system, location_ids: $location_ids, radius_km: $radius_km, corupture_fault_names: $corupture_fault_names, minimum_mag: $minimum_mag, maximum_mag: $maximum_mag, minimum_rate: $minimum_rate, maximum_rate: $maximum_rate}, sortby: $sortby) {\n    total_count\n  }\n  ...RuptureAnimationPage_queryRoot_2Ls9it\n}\n\nfragment RuptureAnimationPage_queryRoot_2Ls9it on Query {\n  SOLVIS_filter_ruptures(first: $first, after: $after, filter: {model_id: $model_id, fault_system: $fault_system, location_ids: $location_ids, radius_km: $radius_km, corupture_fault_names: $corupture_fault_names, minimum_mag: $minimum_mag, maximum_mag: $maximum_mag, minimum_rate: $minimum_rate, maximum_rate: $maximum_rate}, sortby: $sortby) {\n    pageInfo {\n      hasNextPage\n      endCursor\n    }\n    edges {\n      node {\n        fault_surfaces\n        magnitude\n        rate_weighted_mean\n        area\n        length\n        id\n        __typename\n      }\n      cursor\n    }\n  }\n}\n",

"variables":{"first":5,"after":null,"model_id":"NSHM_v1.0.4","fault_system":"HIK","location_ids":["WLG"],"radius_km":30,"corupture_fault_names":[],"minimum_mag":6,"maximum_mag":10,"minimum_rate":1e-20,"maximum_rate":1,"sortby":null}}

[chrisbc]

So the solvis API results are consistent but the stored / cached dynamodb values have some issues. The entire set should be recalcluated, and/or we look into doing away with stored altogether?

[chrisbc]

FINAL: we no longer pre-calculate these ... so not possible to get these out-of-sync.