Changes between Version 2 and Version 3 of Ticket #13


Ignore:
Timestamp:
Dec 31, 1969, 4:21:07 PM (54 years ago)
Author:
Peter Powers
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #13 – Description

    v2 v3  
    77Notes:
    88Everywhere 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.
     9Dir1 = [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]
     10The 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.
    1111
    1212Why 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:
     13Every 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:
    1414
    1515{{{