Daniel and Robert, Yes, you are correct about scikit-fmm, the dx argument is just to pass different grid sizes in the (dx, dy, dz) directions.
scikit-fmm could be adapted to work on non-uniform (but still structured) grids. The basics of the algorithm would be unchanged but the quadratic equation solved to update each point would be different and a data structure to hold the grid spacing would be needed. Code-wise we would create a new sub-class of the BaseMarcher class that has new updatePointOrderOne and updatePointOrderTwo functions. A few other things, like initializing the initially frozen points and the narrow band, may also need to change. Also, the Sethian book has the formulation for the fast marching method on unstructured grids which we could implement. I will also try to find some time to investigate this and get back to this list. Also, we have a scikit-fmm specific list http://groups.google.com/group/scikit-fmm if the discussion becomes more about scikit-fmm. Thanks, Jason On Tue, Jul 22, 2014 at 2:18 PM, Daniel Wheeler <[email protected]> wrote: > On Tue, Jul 22, 2014 at 2:21 PM, Robert R. Howell <[email protected]> wrote: >> >> Hi Daniel >> >> Thanks for the very quick reply. >> >> I looked at the skfmm code again and unfortunately I think the array >> nature of dx in the travel_time() function is just to pass different >> grid sizes in the (dx, dy, dz) directions when you have a >> multidimensional grid. I don't believe it allows the grid to change >> spacing along any given direction. The most relevant section of the >> code to demonstrate that comes in the pre_process function within >> pffm.py, where it rearranges the input parameters before passing them to >> the c code. It takes the input dx and does the following: >> >> if type(dx) is float or type(dx) is int: >> dx = [dx for x in range(len(phi.shape))] >> dx = np.array(dx) > > > You're completely right. It doesn't support non-uniform grids. I just looked > through the LSMLIB code and that doesn't either. The only way to deal with > this then is to fix either Scikit-fmm or LSMLIB. My hunch is that Scikit-fmm > is probably less work, but I might give it a go with both if I do this and > see what sort of quagmire I end up generating (unless you want to give it a > shot). Anyway, this will be more work than I thought so I can't give you a > time frame on implementing this. Sorry to raise false hopes. I do think that > this is an important issue that impacts my own research so I am motivated to > deal with it. > > -- > Daniel Wheeler > > _______________________________________________ > fipy mailing list > [email protected] > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > -- -- Jason K. Furtney Itasca Consulting Group 111 3rd Ave. South, Suite 450 Minneapolis, MN 55401 USA (612) 371-4711 _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
