oq-engine icon indicating copy to clipboard operation
oq-engine copied to clipboard

disaggregation by lon-lat-trt yields high hazard contributions from outside the integration distance

Open kejohnso opened this issue 2 years ago • 2 comments

In the disaggregation by LLT, the contribution is being attributed mostly to a spatial bin without any sources, and which is outside the integration distance. It could be related to multifaults.

kejohnso avatar May 20 '22 07:05 kejohnso

@micheles @mmpagani

The problem is in identifying the closest point on the rupture surface to the site for multifaults. The function get_closest_points finds which surface is closest to the site based on the rrup distance, and then computes the closest point on that surface. The bug is that if the last surface in the list of surfaces is not the closest one, then no calculation is done, and the lons and lats arrays created by np.empty_like() keep the distance rrup instead. I have proposed a solution here and tested it in a few small cases, but I'm not sure if it's the most elegant way and should probably be tested further.

kejohnso avatar Jun 04 '22 16:06 kejohnso

Thanks for the analysis, @kejohnso . I will leave the ball to @mmpagani

micheles avatar Jun 05 '22 05:06 micheles

@micheles @mmpagani

This issue is partially solved by what's written above, but the problem is more complex. Here is what I have found:

  • in the datastore (dstore['rup']), some ruptures incorrectly have clat or clon values of 0.0, despite that the test model is centered on ~70.7 W 19.5 N
Screenshot 2022-08-16 at 09 10 58
  • the problematic ruptures do not seem to correspond to a specific source or source typology. For example, if the problematic source is isolated from a larger source model and run by itself, everything is correct.
  • for all sources, what is returned by get_ctxs seems to be correct, so I don't think it's related to computation of clat and clon. the error occurs sometime between the cmaker and where the rup_data dictionary is written to the dstore. I tracked this as far as where Starmap is used but don't understand how to test what happens next...

I will send the test job files and some more analysis separately.

kejohnso avatar Aug 16 '22 07:08 kejohnso

@micheles the error is still there. Using the test case provided by @kejohnso, in agg_dicts the object dic['source_data'] already contains clon = 0 (and clat has values that should be assigned to clon). Seems like a problem with indexes ... perhaps in the tiling mechanism.

mmpagani avatar Aug 16 '22 11:08 mmpagani