<div dir="ltr">On Fri, Oct 4, 2013 at 9:55 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Asmund,<br>
<br>
You can use the DMDA to manage the layout of your velocity variables as well as the pressure variables. You will have two DMDA, one that manages the cell-centered pressure variables (this is created with the dof argument of 1) and one that handles the velocities (that is created with the dof argument of 3) on the "faces". Then you can have a ghosted representation of the velocities from which you compute the right hand side for your pressure equation. </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What kind of boundary conditions do you have for the velocities? This will determine exactly how to create the DMDA for the velocities.<br>
<br>
Note the though the x, y, and z velocities are physically associated with the three sets of faces of the cells and thus not collocated on the physical domain you can stack the three of them up at the same i,j,k mesh point of the DMDA vector. Depending on your boundary conditions there may be less pressure variables then velocity variables in each direction of the grid; to make the two different DMDA "line up" you can just have an extra "slab" of pressure variables in each direction that are never computed on. It's easy to draw a picture in 2d of the stagger grid to see what I mean.</blockquote>
<div><br></div><div>Note that you no longer have to do this, since you can use PetscSection and DMCreateSubDM(), but you may not want</div><div>to tell people to do this yet.</div><div><br></div><div> Matt</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Oct 4, 2013, at 8:35 AM, Åsmund Ervik <<a href="mailto:asmund.ervik@ntnu.no">asmund.ervik@ntnu.no</a>> wrote:<br>
<br>
> Dear all,<br>
><br>
> We have a two-phase incompressible Navier-Stokes solver written in<br>
> Fortran where we use PETSc for solving the pressure Poisson equation.<br>
> Since both PETSc and parallelism was an afterthought to this code, it<br>
> doesn't scale well at all, so I am tasked with re-writing the whole<br>
> thing now. Before I commit any fresh mistakes in the design of this new<br>
> code, I will ask for input on my "design decisions" so far.<br>
><br>
> I want to do domain decomposition on a structured 3D grid. I've been<br>
> trying to wrap my head around the DM and DMDA parts of PETSc, and as far<br>
> as I understand, these will help me solve the pressure Poisson equation<br>
> on a decomposed domain (and with geometric multigrid via Galerkin)<br>
> fairly easily.<br>
><br>
> The tricky part, then; it seems that I must handle "the rest" of the<br>
> domain decomposition myself. Omitting some detail, this means my code will:<br>
><br>
> * set up parameters, initial conditions, etc.<br>
> * decompose my array for the velocity field into several parts,<br>
> * time loop:<br>
> * communicate e.g. the velocity field on the boundaries<br>
> * each mpi worker will calculate on the local domain the<br>
> intermediate velocity field, the rhs to the Poisson equation<br>
> and set up the correct sparse matrix<br>
> * PETSc will solve the Poisson equation to give me the pressure<br>
> * each mpi worker will then calculate the updated<br>
> divergence-free velocity field<br>
> * each mpi worker will calculate the time step (CFL condition),<br>
> and we choose the lowest dt among all nodes<br>
> * end time loop<br>
><br>
> Have I misunderstood anything here? At first I thought the DMDA would<br>
> give me the framework for decomposing the velocity field, handling<br>
> communication of the ghost values at the boundaries etc, but it seems<br>
> this is not the case?<br>
><br>
> One further question: is it a good idea to set up the DMDA letting PETSc<br>
> decide the number of processors in each direction, and then using this<br>
> same partition for the rest of my code?<br>
><br>
> If there are any unclear details, please ask. If it matters, I am using<br>
> the level-set and ghost-fluid methods, so the matrix for my Poisson<br>
> equation must be recomputed each time step. I believe this is the same<br>
> situation as Michele Rosso who posted on this list recently.<br>
><br>
> Best regards,<br>
> Åsmund Ervik<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>