mesh_ribbon development with endpoint ordering

[jploveless]

I don't have everything figured out (some weird indexing issues that I don't quite understand, described below) but this branch will now produce a ribbon mesh, I think addressing some of the issues in #105.

The main change (in fact, the only real change) made was to first order the segment endpoints before crawling to order them. I did this with the old style of just placing the western endpoint first (because segment.x1, segment.y1, etc. were not created). This seems to solve the issue from #105, in that one segment was getting stuck because it was only finding itself as having a matching endpoint.

Some other changes:

• resample_trace now uses arrays rather than df or df_keep, since I think that the ordered coordinates should always be 1 entry longer than the segments
• BUT, for some reason there was a (0, 0) coordinate as the last entry of ordered_segment_lon and _lat, so I had to trim these upon calling resample_trace. I don't understand this, but I think it's related to the original allocation of these coordinate arrays?
• Hard coded locking_depth and dip array values for now for the arrays passed to resample_trace
• Commented out plotting the segments themselves and dropping into REPL because it was hanging for me

[jploveless]

https://github.com/brendanjmeade/celeri/pull/106/commits/dcd89c9fc772ad7f34b63350c88b8184f19d1f63 addresses some of the indexing issues. I did remove dip as a variable passed to resample_trace because I feel like that's a property of the segments, not a property of the coordinates. In my past mesh-rotating schemes, I've only worked with a single dip value applied uniformly to the entire perimeter, but I'd be interested in revisiting this.

Locking depths are now assigned to the ordered coordinates, just so their array size remains consistent with the longitude and latitude. I assigned locking depths to a coordinate that is shared by 2 segments as the average of those segments' locking depths, but that's makes for some funky looking meshes, because it's one-sided: where there's a change in locking depth, the "next" coordinate in order is assigned an average depth, which propagates along the ordered coordinates, but really it should also be backward looking to smooth out these changes.

I tested a few element sizes and resample lengths, and it makes pretty good looking meshes. Non-resampling looks pretty terrible with almost no interpolation between the top and bottom coordinates.

[brendanjmeade]

This looks awesome @jploveless

https://github.com/brendanjmeade/celeri/commit/dcd89c9fc772ad7f34b63350c88b8184f19d1f63 addresses some of the indexing issues. I did remove dip as a variable passed to resample_trace because I feel like that's a property of the segments, not a property of the coordinates. In my past mesh-rotating schemes, I've only worked with a single dip value applied uniformly to the entire perimeter, but I'd be interested in revisiting this.

Agreed that we should revisit dip. I had passed dip because it would be useful for calculating the bottom coordinates. It was a little trickier than I thought because with different dips on adjacent segments we'd need to do something like average the dips and strikes at corners...or something. Definitely worth revisiting in the future.

Locking depths are now assigned to the ordered coordinates, just so their array size remains consistent with the longitude and latitude. I assigned locking depths to a coordinate that is shared by 2 segments as the average of those segments' locking depths, but that's makes for some funky looking meshes, because it's one-sided: where there's a change in locking depth, the "next" coordinate in order is assigned an average depth, which propagates along the ordered coordinates, but really it should also be backward looking to smooth out these changes.

Maybe, for the purpose of meshing, we could introduce a central segment coordinate that might help with the depth interpolation. Not sure that enough of a solution. It feels like, long term, this should be rolled together with the future dip calculations.

I tested a few element sizes and resample lengths, and it makes pretty good looking meshes. Non-resampling looks pretty terrible with almost no interpolation between the top and bottom coordinates.

Great that the resampling makes a difference!