Custom Query (454 matches)
Results (10 - 12 of 454)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#13 | fixed | fix RelativeLocation.getLocation(Loc, Dir) sign problem | ||
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. |
|||
#14 | fixed | Atten Rel Plotter printing bugs | ||
Description |
When printing data from the Attenuation Relationship Plotter, I can only get the a truncated first line of the parameters (see attached scan). Also, the last line of data on each page is garbled. Any suggestions for a fix? Thanks Maurice Amendolagine, P.E., G.E. Senior Geotechnical Engineer GEI Consultants, Inc. 2141 Palomar Airport Road, Suite 160 Carlsbad CA 92011-1463 760-795-1968 direct 760-929-9136 main 760-929-0836 fax mamendolagine@… |
|||
#15 | fixed | test ticket | ||
Description |
dfgdsf dfgsdf dfs gsdf |