Opened 14 years ago
Last modified 14 years ago
#13 closed defect
fix RelativeLocation.getLocation(Loc, Dir) sign problem — at Initial Version
Reported by: | Peter Powers | Owned by: | Peter Powers |
---|---|---|---|
Priority: | major | Milestone: | GEM1 |
Component: | commons | Version: | 0.2 |
Keywords: | Cc: |
Description
RelativeLocation?.getLocation() does not treat Direction as a vector and changes the sign of the depth component.
Facts:
'Direction' is a vector; which way is up is irrelevant.
Seismology, and hence OpenSHA, treat depth as positive down.
Notes:
Everywhere in the code, tests, etc..., depths are entered as positive values. Perfect.
Dir1 = RelativeLocation?.getDirection(Loc1, Loc1) returns the correct vector [i.e. for Loc1(D1=2) and Loc2(D2=4), dV = D2-D1 = 2]
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.
Why the problem hasn't presented itself to date:
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:
vDistance = traceLocation.getDepth() - upperSeismogenicDepth;
vDistance is negative and should be positive:
vDistance = upperSeismogenicDepth - traceLocation.getDepth();
but the sign switch acoomodates the error in getLocation(). Subsequently, the vectors to each down dip node are computed as:
vDistance = -ith_row * gridSpacingSinAveDipRadians
Again, in this case, the sign of ith_row has been changed to accomodate getLocation().
Conclusion:
Change getLocation() and all affected calls (fewer than than the total 71) on the GEM branch for future merging. This won't take too much work and will prevent further confusion.