Opened 14 years ago
Last modified 11 years ago
#36 assigned defect
Standardize use of linearDistanceFast vs linearDistance
| Reported by: | Kevin Milner | Owned by: | Kevin Milner |
|---|---|---|---|
| Priority: | major | Milestone: | OpenSHA 1.4 |
| Component: | sha | Version: | |
| Keywords: | IMR | Cc: |
Description (last modified by )
In working on efficiency for #34, Multi IMR averager, I noticed that results aren't always consistent when calling setPropogationEffect vs calling setSite and setEqkRupture.
Test added at trunk/test/org/opensha/sha/imr/attenRelImpl/test/SetPropEffectTest.java to test this.
This is due to some calculations using linearDistanceFast while others use linearDistance. We need to standardize this, possibly using a calculation parameter to switch between the two.
Change History (8)
comment:1 Changed 14 years ago by
| Description: | modified (diff) |
|---|---|
| Status: | new → assigned |
comment:2 Changed 14 years ago by
| Cc: | Ned Field Peter Powers added |
|---|---|
| Keywords: | IMR added |
comment:3 Changed 14 years ago by
comment:4 Changed 14 years ago by
I did some tests to compare both distance calculation metrics. See results at the DistCalcs wiki page.
comment:5 Changed 14 years ago by
| Description: | modified (diff) |
|---|---|
| Milestone: | OpenSHA 1.1 → OpenSHA 1.2 |
| Summary: | Fix IMRs that yield different results with setPropogationEffect than setSite & setEqkRupture → Standardize use of linearDistanceFast vs linearDistance |
moving to 1.2 and renaming. this will be a big change if we introduce a parameter for setting the distance calculation type.
comment:6 Changed 13 years ago by
| Milestone: | OpenSHA 1.2 → OpenSHA 1.3 |
|---|---|
| Version: | 1.0.x |
putting off to 1.3
comment:7 Changed 13 years ago by
| Cc: | Ned Field Peter Powers removed |
|---|
comment:8 Changed 11 years ago by
| Milestone: | OpenSHA 1.3 → OpenSHA 1.4 |
|---|
putting off to 1.4, or whenever we implement persistent app preferences
The difference here is that propagation effect params use fast distance calculations, but the distance parameters use slow (but more accurate) calculations. We need to reconcile this, possibly with a control panel.