Custom Query (454 matches)

Integrate Ivy with OpenSHA. Build local repository on opensha.usc.edu that syncs with remote repositories.

Need to add instructions for password changing on scec.usc.edu and make checking out a branch/tag clear.

Want to also have trunk be the latest greatest version and tag releases.

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.