Hi Dave, Thank you very much for the useful examples! I have constant smoothing length in my problem, so it fits DMSWARM very well, I am happy to be a beta tester! Any question while using DSWARM, I will drop into this thread.
Best, On Sat, Oct 15, 2016 at 12:29 PM, Dave May <dave.mayhe...@gmail.com> wrote: > > > On 15 October 2016 at 06:17, Dave May <dave.mayhe...@gmail.com> wrote: > >> >> >> On Saturday, 15 October 2016, Barry Smith <bsm...@mcs.anl.gov> wrote: >> >>> >>> Unless the particles are more or less equally distributed over the the >>> entire domain any kind of "domain decomposition" approach is questionably >>> for managing the particles. Otherwise certain processes that have domains >>> that contain most of the particles will have a great deal of work, for all >>> of its particles, while domains with few particles will have little work. I >>> can see two approaches to alleviate this problem. >>> >>> 1) constantly adjust the sizes/locations of the domains to load balance >>> the particles per domain or >>> >>> 2) parallelize the particles (some how) instead of just the geometry. >>> >>> Anyways, there is a preliminary DMSWARM class in the development version >>> of PETSc for helping to work with particles provided by Dave May. You might >>> look at it. I don't know if it would useful for you or not. IMHO software >>> library support for particle methods is still very primitive compared to >>> finite difference/element support, in other words we still have a lot to do. >> >> >> If you are using an SPH formulation with a constant smoothing length >> (such as for incompressible media), then DMSWARM will be extremely useful. >> It manages the assignment of fields on point clouds and managed data >> exchanges required for particle advection and gather operations from >> neighbor cells required for evaluating the SPH basis functions. >> >> DMSWARM is in the master branch. We would be happy if you want to be beta >> tester. The API is in its infancy and thus having a user play with what's >> there would be the best way to refine the design as required. >> >> Take a look at the examples and let us know if you need help. >> > > > Specifically look at these examples (in the order I've listed) > > * src/dm/examples/tutorials/swarm_ex2.c > Demonstrates how to create the swarm, register fields within the swarm and > how to represent these fields as PETSc Vec objects. > > * src/dm/examples/tutorials/swarm_ex3.c > This demonstrates how you push particles from one sub-domain to another. > > * src/dm/examples/tutorials/swarm_ex1.c > This demonstrates how to define a collection operation to gather particles > from neighbour cells (cells being defined via DMDA) > > There isn't a single complete example using a DMSWARM and DMDA for > everything required by SPH, but all the plumbing is in place. > > Thanks, > Dave > > >> >> Thanks, >> Dave >> >> >>> >>> >>> Barry >>> >>> >>> >>> >>> >>> > On Oct 14, 2016, at 9:54 PM, Sang pham van <pvsang...@gmail.com> >>> wrote: >>> > >>> > Hi Barry, >>> > >>> > Thank your for your answer. I am writing a parallel code for >>> smoothed-particle hydrodynamic, in this code I used a DMDA background mesh >>> for management of particles. Each DMDA cell manages a number of particles, >>> the number can change in both time and cell. In each time step, I need to >>> update position and velocity of particles in border cells to neighbor >>> partition. I think I can not use DMDA Vec to do this be cause the number of >>> particles is not the same in all ghost cells. >>> > >>> > I think I am able to write a routine do this work, but the code may be >>> quite complicated and not so "formal", I would be very appreciated if you >>> can suggest a method to solve my problem. >>> > >>> > Many thanks. >>> > >>> > >>> > >>> > >>> > On Sat, Oct 15, 2016 at 9:40 AM, Barry Smith <bsm...@mcs.anl.gov> >>> wrote: >>> > >>> > Thanks, the question is very clear now. >>> > >>> > For DMDA you can use DMDAGetNeighborsRank() to get the list of the >>> (up to) 9 neighbors of a processor. (Sadly this routine does not have a >>> manual page but the arguments are obvious). For other DM I don't think >>> there is any simple way to get this information. For none of the DM is >>> there a way to get information about what process is providing a specific >>> ghost cell. >>> > >>> > It is the "hope" of PETSc (and I would think most parallel computing >>> models) that the details of exactly what process is computing neighbor >>> values should not matter for your own computation. Maybe if you provide >>> more details on how you wish to use this information we may have >>> suggestions on how to proceed. >>> > >>> > Barry >>> > >>> > >>> > >>> > > On Oct 14, 2016, at 9:23 PM, Sang pham van <pvsang...@gmail.com> >>> wrote: >>> > > >>> > > Hi Barry, >>> > > >>> > > In 2 processes case, the problem is simple, as I know all ghost >>> cells of partition 0 are updated from partition 1. However, in the case of >>> many processes, how do I know from which partitions ghost cells of >>> partition 0 are updated? In other words, How can I know neighboring >>> partitions of the partition 0? and can I get a list of ghost cells managing >>> by a neighboring partition? >>> > > Please let me know if my question is still not clear. >>> > > >>> > > Many thanks. >>> > > >>> > > >>> > > On Sat, Oct 15, 2016 at 8:59 AM, Barry Smith <bsm...@mcs.anl.gov> >>> wrote: >>> > > >>> > > > On Oct 14, 2016, at 8:50 PM, Sang pham van <pvsang...@gmail.com> >>> wrote: >>> > > > >>> > > > Hi, >>> > > > >>> > > > I am using DM Vec for a FV code, for some reasons, I want to know >>> partition of all ghost cells of a specific partition. is there a way do >>> that? >>> > > >>> > > Could you please explain in more detail what you want, I don't >>> understand? Perhaps give a specific example with 2 processes? >>> > > >>> > > Barry >>> > > >>> > > >>> > > >>> > > > >>> > > > Many thanks. >>> > > > >>> > > > Best, >>> > > > >>> > > >>> > > >>> > >>> > >>> >>> >
