Closed patrickb314 closed 2 years ago
The matrix initialization (lines 86-87 in example1.cpp) needs to be done only once.
If the source or target points are moving between FMM evaluations then you would need to rebuild the tree (PtFMM_CreateTree) and setup the FMM on the tree (SetupFMM) again each time.
If the overhead of rebuilding the tree is significant, then you can try to reuse the same tree structure by updating the source and target points in place, within the tree leaf nodes. This is what fmm_ptr.cpp does. But this is more complicated (and error prone since you are responsible for ensuring that the points are correctly sorted to the leaf nodes) and I don't recommend doing this unless absolutely necessary. You would still need to call the member functions InitFMM_Tree() (normally called within PtFMM_CreateTree) and SetupFMM() on the tree.
Thanks, that's what I needed to know. The particles move enough that trying to keep the tree sorted is probably not something I want to do.
What's the state of things for GPU support right now, BTW? The current cmake build setup doesn't appear to try and detect CUDA support from what I can tell.
Right now PVFMM has GPU support only for computing volume potentials. We might consider adding GPU support for particles if there is sufficient demand for it.. but as of now we are not actively working in that direction.
I'm working on a benchmark that repeatedly calls pvffm to evaluate a biot-savart point-to-point kernel as part of a runge kutta time integration, with the source and target points and potentials changing between each invocation. Are there any particularly strategies, documentation, or examples on how to cut down on or reuse initialization/tree matrix initialization, tree construction or other setup overheads between successive invocations? Is this, for example, what
fmm_pts.cpp
is doing?