<div dir="ltr">On Fri, Oct 4, 2013 at 1:51 PM, Åsmund Ervik <span dir="ltr"><<a href="mailto:asmund.ervik@ntnu.no" target="_blank">asmund.ervik@ntnu.no</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">
<div>
<br>
Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> skrev:<br>
<div dir="ltr">On Fri, Oct 4, 2013 at 12:57 PM, Åsmund Ervik <span dir="ltr"><<a href="mailto:asmund.ervik@ntnu.no" target="_blank">asmund.ervik@ntnu.no</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
<div>Barry,</div>
<div><br>
</div>
<div>Thanks for the quick answer.</div>
<div><br>
</div>
<div>Good to hear that I can use the DMDA framework for all variables. Should I put all scalars (e.g. pressure, level set function, etc) in the same DA, or should I keep a distinct one for the pressure (where I want to use multigrid)?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Separate variables which are solved for.</div>
<div><br>
</div>
<div>Ok. So only variables that belong together, such as the velocity components, should be grouped via the dof?</div></div></div></div></div></blockquote><div><br></div><div>Its just the solved for/not solved for distinction that is important.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
<div>The reason I was unsure is that I can't seem to find an example which manipulates the local array from a DA. I would've guessed there was something like</div>
<div><br>
</div>
<div>real, dimension(:,:,:) u,v,w</div>
<div>call DMDAGetLocalArray(da,u,v,w)</div>
<div>! Some computations looping over local i,j,k that manipulate u,v,w</div>
<div>call DMDARestoreLocalArray(da,u,v,w)</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMDAVecGetArray.html" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMDAVecGetArray.html</a><br>
</div>
<div><br>
</div>
<div>Doh. Thanks. I've been looking at that, and kept focusing on the input which must be a vector, but I see that's just the internal storage format.</div>
<div><br>
</div>
<div>Speaking of storage formats, I would like to have a unified format for checkpointing and visualization output. So that after analyzing a result I could restart from an arbitrary time step in the output. Is the VTK viewer or the binary PETSc viewer the
best way to go? I use Tecplot and Visit today.</div></div></div></div></div></blockquote><div><br></div><div>Right now, this does not exist. The binary format is great for checkpointing, but not for viz. In the future, I predict HDF5, since you</div>
<div>can put Xdmf around it (could also do this for PETSc binary) for viz and it has nice Python tools. Jed probably has an opinion.</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">
<div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
<div>On the BCs for velocity, I would like to support several options. To get the code up and running I would be OK with just periodic, but I would eventually like to support full slip and no slip, and preferably a mix of these for the different faces. Perhaps
also inflow and outflow. I don't need (physical) pressure BCs though. Would this complicate things much?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Both periodic and ghost cells are supported. Imposing Dirichlet conditions on an unknown is also easy.</div>
<div><br>
</div>
<div>Good. I will come back to this if I have specific questions.</div>
<div><br>
</div>
<div>Åsmund</div>
<div><br>
</div>
<div><br>
</div>
<div> Thanks,</div>
<div><br>
</div>
<div> Matt</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
<div>I understand the point about the velocity i,j,k lining up, this is how we do it currently.</div>
<div><br>
</div>
<div>Åsmund</div>
<div><br>
</div>
<div>
<div style="font-size:75%;color:rgb(87,87,87)">Sent from my VT-102</div>
</div>
<br>
Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> skrev:<br>
</div>
<font><span style="font-size:10pt">
<div><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.
<br>
<br>
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.<br>
<br>
<br>
Barry<br>
<br>
On Oct 4, 2013, at 8:35 AM, Åsmund Ervik <<a href="mailto:asmund.ervik@ntnu.no" target="_blank">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><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></span></font></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<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 </font></span></div>
</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>