makeUnion iteratively

[drjosephbrock]

I would like to make use of implicit functions to do an embedded boundary sim with packed spheres. I want the number of spheres to be an input or compile-time option. Since the makeUnion call is a variadic, I am not sure how I can do this? Is there a way I can do this? If not, would writing a default constructor to the UnionIF() class be the best approach? Thanks!

[WeiqunZhang]

You could write your own class for this. Something like

class NSphereIF : public GPUable
{
public:
    // constructors, destructor, and operator=s

   // operator() will loop over spheres

private:
    int nspheres;
    Real* radius;  // radius[i] is the radius of sphere i.
    XDim3* center; // center[i] is the center of sphere i.
};

// Keep these two vectors alive during the EB generation
Gpu::DeviceVector<Real> sphere_radius(...);
Gpu::DeviceVector<XDim3> sphere_center(...);

NSphereIF ns(....); // pass sphere_radius.data() and sphere_center.data() to the constructor.

[john-w-gardner]

Would you still call makeUnion? How would you combine the spheres?

[WeiqunZhang]

No. It's up to you how you create the vectors sphere_radius and sphere_center.

[rmrsk]

How many spheres? Iterating over e.g. 10^5-10^6 spheres can be pretty slow although there are faster ways to do it

[drjosephbrock]

It is definitely slow. I started with 100 spheres, and that was fine. Once I got to 10^4 it became pretty intractable. 10^6 is definitely out of the question.

[rmrsk]

Ok, and obviously that is because

for (int i = 0; i < num_spheres; ++i)

has O(num_spheres) complexity. How many spheres do you need? One can make it O(log num_spheres) on average and I have code for that. But it's not on the GPU (yet) and the timeline for GPU support is also uncertain. Regardless, we've seen > 4000x improvement on the CPU with > 10^5 spheres.

ScalingBVH.pdf

[WeiqunZhang]

What does BVH stand for?

[rmrsk]

Bounding Volume Hierarchy