id summary reporter owner description type status priority milestone component version resolution keywords cc 13 fix RelativeLocation.getLocation(Loc, Dir) sign problem Peter Powers Peter Powers "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 = [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] 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. Why the problem hasn't presented itself to date: 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 [source:/trunk/src/org/opensha/sha/faultSurface/StirlingGriddedSurface.java 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. " defect closed major GEM1 commons 0.2 fixed