tutorial/documentation

[d-chambers]

Hello,

This looks like a very interesting project! Do you have getting started section or some tutorials for using this code (sorry if I missed it)? If so it would be great to put a link in the project's readme file.

Also, the other python package in this space is sk-fmm. One of my first questions is what the differences are between pykonal and sk-fmm, maybe this could be covered as well?

Thanks!

[aleccarruthers]

@d-chambers I'm not affiliated with this project in anyway, but there are some examples here: https://malcolmw.github.io/pykonal-docs/

In addition, does this work for 2-dimensional cases or only 3-D? I have been using the sk-fmm package, but it fails a lot from a negative discriminant issue, which I am hoping this package can resolve.

[d-chambers]

Thanks @aleccarruthers, that is what I was looking for. It would probably be a good idea to put a link to docs in the readme so it is easier to find.

[malcolmw]

@d-chambers Thanks for your interest and your feedback; I will add the information you suggest to the README.

I implemented PyKonal to offer greater flexibility with respect to coordinate systems. Each coordinate system has strengths and weaknesses and should be chosen appropriately for the problem being solved. For example, spherical coordinates are appropriate for treating spherical wavefronts, whereas Cartesian coordinates are appropriate for planar wavefronts. The code currently implements Cartesian and spherical coordinates, and extending to additional coordinate systems (e.g., cylindrical) is straightforward, should that become necessary. As far as I know, sk-fmm only offers Cartesian coordinates.

PyKonal also offers functionality to trace propagation paths, which I believe is missing from sk-fmm.

@aleccarruthers Thanks for pointing @d-chambers to the relevant documentation. And yes, the code does handle the 2D case in both Cartesian or spherical (polar in the 2D case) coordinates. I will make that clearer in the documentation.

@d-chambers @aleccarruthers Please let me know if you have any trouble using the package or if you think any other documentation is missing and needed.

[aleccarruthers]

Hi Malcom,

Thanks for the response. I was wondering if PyKonal is able to provide a similar result to scikit-fmm's "travel_time" function? I have used that in the past with a cost array (each pixel has an associated cost) which is essentially a speed of propagation array. Pixels with the lowest cost (large reciprocal cost) are chosen at each step and ultimately converted into a geodesic distance. Any further information that you can provide would be greatly appreciated.

Thanks, Alec

On Mon, Jun 8, 2020 at 2:23 PM Malcolm White notifications@github.com wrote:

@d-chambers https://github.com/d-chambers Thanks for your interest and your feedback; I will add the information you suggest to the README.

I implemented PyKonal to offer greater flexibility with respect to coordinate systems. Each coordinate system has strengths and weaknesses and should be chosen appropriately for the problem being solved. For example, spherical coordinates are appropriate for treating spherical wavefronts, whereas Cartesian coordinates are appropriate for planar wavefronts. The code currently implements Cartesian and spherical coordinates, and extending to additional coordinate systems (e.g., cylindrical) is straightforward, should that become necessary. As far as I know, sk-fmm only offers Cartesian coordinates.

@aleccarruthers https://github.com/aleccarruthers Thanks for pointing @d-chambers https://github.com/d-chambers to the relevant documentation. And yes, the code does handle the 2D case in both Cartesian or spherical (polar in the 2D case) coordinates. I will make that clearer in the documentation.

@d-chambers https://github.com/d-chambers @aleccarruthers https://github.com/aleccarruthers Please let me know if you have any trouble using the package or if you think any other documentation is missing and needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/malcolmw/pykonal/issues/4#issuecomment-640894812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6D33PLYZVP2OGPE335PYLRVVJE7ANCNFSM4NR2Q2WA .

[aleccarruthers]

To better rephrase my question, if I have a list of nodes that I want to start from, I would just iterate through each of those and calculate a travel time or could I initialize those pixels/nodes with a value of zero, as you did in the docs, and compute the travel time for each of those nodes all at once?

Thanks, Alec

On Mon, Jun 8, 2020 at 5:03 PM Alec Carruthers aleccarruthers5@gmail.com wrote:

Hi Malcom,

Thanks for the response. I was wondering if PyKonal is able to provide a similar result to scikit-fmm's "travel_time" function? I have used that in the past with a cost array (each pixel has an associated cost) which is essentially a speed of propagation array. Pixels with the lowest cost (large reciprocal cost) are chosen at each step and ultimately converted into a geodesic distance. Any further information that you can provide would be greatly appreciated.

Thanks, Alec

On Mon, Jun 8, 2020 at 2:23 PM Malcolm White notifications@github.com wrote:

@d-chambers https://github.com/d-chambers Thanks for your interest and your feedback; I will add the information you suggest to the README.

I implemented PyKonal to offer greater flexibility with respect to coordinate systems. Each coordinate system has strengths and weaknesses and should be chosen appropriately for the problem being solved. For example, spherical coordinates are appropriate for treating spherical wavefronts, whereas Cartesian coordinates are appropriate for planar wavefronts. The code currently implements Cartesian and spherical coordinates, and extending to additional coordinate systems (e.g., cylindrical) is straightforward, should that become necessary. As far as I know, sk-fmm only offers Cartesian coordinates.

@aleccarruthers https://github.com/aleccarruthers Thanks for pointing @d-chambers https://github.com/d-chambers to the relevant documentation. And yes, the code does handle the 2D case in both Cartesian or spherical (polar in the 2D case) coordinates. I will make that clearer in the documentation.

@d-chambers https://github.com/d-chambers @aleccarruthers https://github.com/aleccarruthers Please let me know if you have any trouble using the package or if you think any other documentation is missing and needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/malcolmw/pykonal/issues/4#issuecomment-640894812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6D33PLYZVP2OGPE335PYLRVVJE7ANCNFSM4NR2Q2WA .

[malcolmw]

@aleccarruthers I am not sure I completely understand, but let me take a crack at answering.

You can always access the array of traveltimes at each node of the computational grid (pixels in your application) via the EikonalSolver.traveltime.values attribute.

You can initialize multiple nodes with a traveltime of zero (or any other value for that matter)—call these "source" nodes. What you get after calling EikonalSolver.solve() in that case is the traveltime to each grid node from the closest (in terms of time) source node.

If you want to know how long it takes to get to point B from every other point in the grid, you can treat the destination (point B) as the source node and call EikonalSolver.solve(). The value of the resultant traveltime field at each node will be the traveltime from point B to that node, which is the same as the traveltime from that node to point B.

Does that help?

[aleccarruthers]

Yea, that helps. I am using this for river/stream extraction, so I don't necessarily know where they end, just the likely start. I will try to initialize the nodes I have as sources and see where that takes me. Thank you.

Thanks, Alec

On Mon, Jun 8, 2020 at 5:54 PM Malcolm White notifications@github.com wrote:

@aleccarruthers https://github.com/aleccarruthers I am not sure I completely understand, but let me take a crack at answering.

You can always access the array of traveltimes at each node of the computational grid (pixels in your application) via the EikonalSolver.traveltime.values attribute.

You can initialize multiple nodes with a traveltime of zero (or any other value for that matter)—call these "source" nodes. What you get after calling EikonalSolver.solve() in that case is the traveltime to each grid node from the closest (in terms of time) source node.

If you want to know how long it takes to get to point B from every other point in the grid, you can treat the destination (point B) as the source node and call EikonalSolver.solve(). The value of the resultant traveltime field at each node will be the traveltime from point B to that node, which is the same as the traveltime from that node to point B.

Does that help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/malcolmw/pykonal/issues/4#issuecomment-640964038, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6D33LYOFSK6UXM2MU573DRVWB37ANCNFSM4NR2Q2WA .

[aleccarruthers]

Also, I just received this type of error for both "is_far" and "close." I'm not really sure why that is wrong as that is what the documentation shows.

On Mon, Jun 8, 2020 at 7:03 PM Alec Carruthers aleccarruthers5@gmail.com wrote:

Yea, that helps. I am using this for river/stream extraction, so I don't necessarily know where they end, just the likely start. I will try to initialize the nodes I have as sources and see where that takes me. Thank you.

Thanks, Alec

On Mon, Jun 8, 2020 at 5:54 PM Malcolm White notifications@github.com wrote:

@aleccarruthers https://github.com/aleccarruthers I am not sure I completely understand, but let me take a crack at answering.

You can always access the array of traveltimes at each node of the computational grid (pixels in your application) via the EikonalSolver.traveltime.values attribute.

You can initialize multiple nodes with a traveltime of zero (or any other value for that matter)—call these "source" nodes. What you get after calling EikonalSolver.solve() in that case is the traveltime to each grid node from the closest (in terms of time) source node.

If you want to know how long it takes to get to point B from every other point in the grid, you can treat the destination (point B) as the source node and call EikonalSolver.solve(). The value of the resultant traveltime field at each node will be the traveltime from point B to that node, which is the same as the traveltime from that node to point B.

Does that help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/malcolmw/pykonal/issues/4#issuecomment-640964038, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6D33LYOFSK6UXM2MU573DRVWB37ANCNFSM4NR2Q2WA .

[malcolmw]

@aleccarruthers Those attributes have been deprecated in favour of the unknown and trial attributes, respectively. I will have to update the documentation. Which page did you find that error on?

[aleccarruthers]

It’s on the examples page, 2d case.

Thanks, Alec

Sent from my iPhone

On Jun 9, 2020, at 6:29 AM, Malcolm White notifications@github.com wrote:

 Those attributes have been deprecated in favour of the unknown and trial attributes, respectively. I will have to update the documentation. Which page did you find that error on?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[malcolmw]

Thanks. Fixed.

I'm going to close this thread. Please open a new thread if you have any other questions, feedback, or bug reports.