Fixed orientation issue / rake is required to be set in set_corners() #323
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@rjleveque Thanks for the comments from github.com/rjleveque/geoclaw/pull/3. I've made some fixes in this PR.
[1-3] I think I mistakenly did a double-negative. I defined a logical
self._fix_orientation
: when it switches on (the orientation is clock-wise), I multiply a negative sign to fix the sign error. I agree that the data user input should be preserved, probably can confuse the user.[4-5] I removed the optional
rake=90.
argument toself.calculate_geometry_triangles()
and also made therake
input required forself.set_corners()
, as suggested. (I think in the past I looked through all the triangular subfaults in CSZ and seeing them all having rake of 90 degrees I assumed that 90 degrees was the default for most cases.)[6] I am not sure where to specify that the user needs to install
utm
andpyproj
... and yes, I think the discrepancy should be due to the various differences in transforming from long-lat to meters - there is actually a subtle issue here: for the triangular case, the method needs the deformations originating from each of the corners of the triangle to cancel exactly.