Getting direction to nearest zero point

[Ali2500]

The distance() method returns the signed distance to the nearest point on the contour given by phi, but is it also possible to somehow get an angle or vector indicating the direction of this nearest point? I'm assuming this is already computed internally when the fast marching algorithm is implemented, but can I somehow access this?

I guess it could also be done by taking the gradient of the signed distance, but it just seems like additional overhead.

[jkfurtney]

Hi and thanks for the message. The gradient is calculated internally but it is not stored. I think you can use numpy.gradient (https://docs.scipy.org/doc/numpy/reference/generated/numpy.gradient.html) for that.

…

On Wed, Jun 26, 2019 at 11:16 AM Ali ***@***.***> wrote: The distance() method returns the signed distance to the nearest point on the contour given by phi, but is it also possible to somehow get an angle or vector indicating the direction of this nearest point. I'm assuming this is already computed internally when the fast marching algorithm is implemented, but can I somehow access this? I guess it could also be done by taking the gradient of the signed distance, but it just seems like additional overhead. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=AAETOAD5IVZUOVDIEDKWDLDP4OP6NA5CNFSM4H3UMKVKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G33VHWQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAETOAG6OR2C35ECA62ZTPDP4OP6NANCNFSM4H3UMKVA> .

[Ali2500]

I actually managed to implement this functionality in the code. Just added another array to the BaseMarcher class that keeps track of the nearest phi==0 point while the FMM is running. Do you think it would make sense to create a pull request for this? There's the memory overhead of another array, but otherwise this info comes for free. In any case it could be made optional.

[jkfurtney]

Ali, thanks for the message and for your efforts on this. Yes, I think this would be a good feature. Adding an optional argument return_gradient with the default value False would allow us to keep backward compatibility. We should think if we can also support this for the travel_time function. Could you put together a pull request? I am on vacation until July 8th but can have a look when I get back.

…

On Thu, Jun 27, 2019 at 10:16 AM Ali ***@***.***> wrote: I actually managed to implement this functionality in the code. Just added another array to the BaseMarcher class that keeps track of the nearest phi==0 point. Do you think it would make sense to create a pull request for this? There's the memory overhead of another array, but otherwise this info comes for free. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=AAETOAAF5CJDYB3KLHD6LFDP4TRWBA5CNFSM4H3UMKVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXUFNA#issuecomment-506413748>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAETOAARWW3UWRHAC53OB2LP4TRWBANCNFSM4H3UMKVA> .

[wmoebius]

Ali and Jason, I'd be very interested in having the same functionality for the travel_time function.

I'm also thinking, but can't quite decide, whether we could store information to get the full path back without needing to follow a gradient as in experimental wmoebius/OptPath.