Changes between Version 2 and Version 3 of Ticket #13
- Timestamp:
- Dec 31, 1969, 4:21:07 PM (54 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #13 – Description
v2 v3 7 7 Notes: 8 8 Everywhere in the code, tests, etc..., depths are entered as positive values. Perfect. 9 Dir1 = source:/trunk/src/org/opensha/commons/calc/RelativeLocation.java RelativeLocation.getDirection(Loc1, Loc1) returns the correct vector [i.e. for Loc1(D1=2) and Loc2(D2=4), dV = D2-D1 = 2]10 The expectation from vector math is that Loc1 + Dir1 = Loc2. However, RelativeLocation.getLocation(Loc, Dir) does NOT produce this result. Rather than adding the depth component of the Dir1, it subtracts it (D2 = D1-dV = 0). This is wrong.9 Dir1 = [source:/trunk/src/org/opensha/commons/calc/RelativeLocation RelativeLocation].getDirection(Loc1, Loc1) returns the correct vector [i.e. for Loc1(D1=2) and Loc2(D2=4), dV = D2-D1 = 2] 10 The expectation from vector math is that Loc1 + Dir1 = Loc2. However, [source:/trunk/src/org/opensha/commons/calc/RelativeLocation RelativeLocation].getLocation(Loc, Dir) does NOT produce this result. Rather than adding the depth component of the Dir1, it subtracts it (D2 = D1-dV = 0). This is wrong. 11 11 12 12 Why the problem hasn't presented itself to date: 13 Every call (~71) to RelativeLocation.getLocation(Loc, Dir) that is interested in depth makes up for this error by switching the sign at some earlier point. As an example, when initializing a StirlingGriddedSurface the vector from the trace to top of seismogenic rupture is computed as:13 Every call (~71) to [source:/trunk/src/org/opensha/commons/calc/RelativeLocation RelativeLocation].getLocation(Loc, Dir) that is interested in depth makes up for this error by switching the sign at some earlier point. As an example, when initializing a StirlingGriddedSurface the vector from the trace to top of seismogenic rupture is computed as: 14 14 15 15 {{{