Fixed orientation issue / rake is required to be set in set_corners()

[dsrim]

@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 to self.calculate_geometry_triangles() and also made the rake input required for self.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 and pyproj ... 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.

[rjleveque]

Thanks @dsrim!

Looking again at the code, maybe it is best if set_corners does not take rake as an argument at all, since this function just sets self._corners and then calls calculate_geometry_triangles, which as far as I can see does not require the rake, only the corners. To apply okada the rake must be set, but so must the slip. Why set one in set_corners and not the other? It seems simplest to have set_corners just sets up the geometry doing what its name indicates, and then assume the user sets the rake and slip elsewhere.

Also, at some point we should try to fix this so that a vertical fault works too, but not urgent.

[dsrim]

@rjleveque That makes more sense. I removed rake as input argument in self.set_corners and it is no longer set there. It's up to the user to set those.

As for the vertical fault - there's nothing mathematically that should prevent this... so I suspect there should be a nice fix. Let me get around to this at some point (hopefully there aren't any vertical subfaults in the meanwhile...)

[rjleveque]

Thanks @dsrim! This looks good now except I notice I left in a couple debug statements that should be removed, the lines

            print('+++ initial strike_deg = %g' % strike_deg)
and
            print('+++ initial dip_deg = %g' % dip_deg)

[dsrim]

@rjleveque debug statements removed!