fix RelativeLocation.getLocation(Loc, Dir) sign problem

[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 = 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.

[Peter Powers]

This has been fixed on trunk and merged back to the GEM branch. Notes on files affected follow:

Changes to the following result in very slight changes to values but this has to do with the assumption that back azimuth and azimuth are complementary. (azimuth and back azimuth had been reversed when creating Directions to compensate for RelativeLocation bug)

org.opensha.sha.gui.controls.PuenteHillsScenarioControlPanel (12)
org.opensha.sha.gui.controls.PuenteHillsScenarioControlPanelForSingleMultipleAttenRel (12)
org.opensha.sha.gui.controls.PuenteHillsScenarioControlPanelUsingEqkRuptureCreation (12)

FaultTraceUtils.getEqualLengthSubsectionTraces()

-- seems to assume no change in depth (probably not a good assumption)

FaultTraceUtils.resampleTrace()

-- should be ok without any changes

Changes to the following fixed a long-standing bug wherein the negative vertical component carried through to a negative horizontal component. If fault trace depths happen to equal topSeismogenicDepth, there is no problem.

org.opensha.sha.faultSurface.StirlingGriddedSurface
org.opensha.sha.faultSurface.FrankelGriddedSurface
org.opensha.sha.faultSurface.SimpleListricGriddedSurface