Hello! Thanks, it's getting a lot more understandable. But some things are not completely clear.
> But instead of passing the > neighborhood object it got from the SerialSimulator, it will pass > on a new neighborhood object[3], a MultiNeighborhoodAdapter[4]. > This has two members, called "spheres" and "boundaries", which are > generated in the expansion of the macro > DECLARE_MULTI_CONTAINER_CELL(). Yes, I got this thing about multicontainer, but to fully understand the mechanics, FloatCoord<> pos somehow connected to the grid? I would like to think that yes, because how else to find neighbors. And if yes, I'd like to discover where this connection is (I believe that < This object does the translation from the neighborhood < that is defined on the regular grid towards iterating over < spheres (or boundaries) something, that could use this connection). From my point of view, this should be something like this: the positions of the spheres should be associated with the grid cells, and thus, it would be possible to recognize directly through the neighboring cells the spheres that occupy these cells, and then resolve collision (if any). But I don't actually see, which cells, to be exact, which adapter recognized as a neighbor? I written down my thoughts into a proposal draft in "Implementation details" paragraph. You could check it, to understand why I'm asking this. Next my question directly relative to this thoughts: is there a possibility to make object take up several cells? Sincerely, Evgeny Dedov
_______________________________________________ hpx-users mailing list hpx-users@stellar.cct.lsu.edu https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
