<div dir="ltr">Hi Dave,<div><br></div><div>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!</div><div>Any question while using DSWARM, I will drop into this thread. </div><div><br></div><div>Best,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 15, 2016 at 12:29 PM, Dave May <span dir="ltr"><<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 15 October 2016 at 06:17, Dave May <span dir="ltr"><<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_8662533497164016191gmail-"><br><br>On Saturday, 15 October 2016, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  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.<br>
<br>
1) constantly adjust the sizes/locations of the domains to load balance the particles per domain or<br>
<br>
2)  parallelize the particles (some how) instead of just the geometry.<br>
<br>
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.</blockquote><div><br></div></span>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. <div><br></div><div>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.</div><div><br></div><div>Take a look at the examples and let us know if you need help.</div></blockquote><div><br><br></div></span><div>Specifically look at these examples (in the order I've listed)<br></div><div><br></div><div>* src/dm/examples/tutorials/<wbr>swarm_ex2.c<br></div><div>Demonstrates how to create the swarm, register fields within the swarm and how to represent these fields as PETSc Vec objects.<br></div><div><br></div><div>* src/dm/examples/tutorials/<wbr>swarm_ex3.c<br></div><div>This demonstrates how you push particles from one sub-domain to another. <br></div><div><br>* src/dm/examples/tutorials/<wbr>swarm_ex1.c<br><div>This demonstrates how to define a collection operation to gather particles from neighbour cells (cells being defined via DMDA)<br></div><div><br></div><div>There isn't a single complete example using a DMSWARM and DMDA for everything required by SPH, but all the plumbing is in place. <br></div><br></div><div>Thanks,<br></div><div>  Dave<br></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div>Thanks,</div><div>  Dave<span class="m_8662533497164016191gmail-"><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
  Barry<br>
<br>
<br>
<br>
<br>
<br>
> On Oct 14, 2016, at 9:54 PM, Sang pham van <<a>pvsang002@gmail.com</a>> wrote:<br>
><br>
> Hi Barry,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Many thanks.<br>
><br>
><br>
><br>
><br>
> On Sat, Oct 15, 2016 at 9:40 AM, Barry Smith <<a>bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>   Thanks, the question is very clear now.<br>
><br>
>   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.<br>
><br>
>   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.<br>
><br>
>   Barry<br>
><br>
><br>
><br>
> > On Oct 14, 2016, at 9:23 PM, Sang pham van <<a>pvsang002@gmail.com</a>> wrote:<br>
> ><br>
> > Hi Barry,<br>
> ><br>
> > 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?<br>
> > Please let me know if my question is still not clear.<br>
> ><br>
> > Many thanks.<br>
> ><br>
> ><br>
> > On Sat, Oct 15, 2016 at 8:59 AM, Barry Smith <<a>bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > > On Oct 14, 2016, at 8:50 PM, Sang pham van <<a>pvsang002@gmail.com</a>> wrote:<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > 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?<br>
> ><br>
> >   Could you please explain in more detail what you want, I don't understand? Perhaps give a specific example with 2 processes?<br>
> ><br>
> >  Barry<br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > > Many thanks.<br>
> > ><br>
> > > Best,<br>
> > ><br>
> ><br>
> ><br>
><br>
><br>
<br>
</blockquote></span></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>