<div dir="ltr">Hi all,<div><br></div><div>Just retouching in case my mail was lost, does my problem make enough sense? I could try to be clearer if you like. I tried using TSGetStages() in the middle of the RHS function but that didn't work. Maybe we can find a different approach for this ?</div><div><br></div><div>Thanks, </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 24, 2019 at 12:58 PM Manuel Valera <<a href="mailto:mvalera-w@sdsu.edu">mvalera-w@sdsu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello all,<div><br></div><div>I finally implemented the TS routine operating in several DAs at the same time, hacking it as you suggested. I still have a problem with my algorithm though. It is not DMDA related so there's that.</div><div><br></div><div>My algorithm needs to update u,v,w with information from the updated T,S,rho. My problem, or what I don't understand yet, is how to operate in the intermediate runge-kutta time integration states inside the RHSFunction. </div><div><br></div><div>If I can be more clear, I would need the intermediate T,S states to obtain an updated rho (density) to in turn, obtain the correct intermediate velocities, and keep the loop going. As I understand right now, the RHS vector is different from this intermediate state, and it would be only the RHS input to the loop, so operating on this would be incorrect. </div><div><br></div><div>As of now, my algorithm still creates artifacts because of this lack of information to accurately update all of the variables at the same time. The problem happens as well in serial.</div><div><br></div><div>Thanks for your help,</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019 at 4:36 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Sep 17, 2019 at 8:27 PM Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  Don't be too quick to dismiss switching to the DMStag you may find that it actually takes little time to convert and then you have a much less cumbersome process to manage the staggered grid. Take a look at src/dm/impls/stag/examples/tutorials/ex2.c where<br>
<br>
const PetscInt dof0 = 0, dof1 = 1,dof2 = 1; /* 1 dof on each edge and element center */<br>
    const PetscInt stencilWidth = 1;<br>
    ierr = DMStagCreate2d(PETSC_COMM_WORLD,DM_BOUNDARY_NONE,DM_BOUNDARY_NONE,7,9,PETSC_DECIDE,PETSC_DECIDE,dof0,dof1,dof2,DMSTAG_STENCIL_BOX,stencilWidth,NULL,NULL,&dmSol);CHKERRQ(ierr);<br>
<br>
BOOM, it has set up a staggered grid with 1 cell centered variable and 1 on each edge. Adding more the cell centers, vertices, or edges is trivial.<br>
<br>
  If you want to stick to DMDA you <br>
<br>
"cheat". Depending on exactly what staggering you have you make the DMDA for the "smaller problem" as large as the other ones and just track zeros in those locations. For example if velocities are "edges" and T, S are on cells, make your "cells" DMDA one extra grid width wide in all three dimensions. You may need to be careful on the boundaries deepening on the types of boundary conditions. <br></blockquote><div><br></div><div>Yes, SNES ex30 does exactly this. However, I still recommend looking at DMStag. Patrick created it because managing the DMDA</div><div>became such as headache.</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:1px solid rgb(204,204,204);padding-left:1ex">
> On Sep 17, 2019, at 7:04 PM, Manuel Valera via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> <br>
> Thanks Matthew, but my code is too complicated to be redone on DMStag now after spending a long time using DMDAs,<br>
> <br>
> Is there a way to ensure PETSc distributes several DAs in the same way? besides manually distributing the points,<br>
> <br>
> Thanks, <br>
> <br>
> On Tue, Sep 17, 2019 at 3:28 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
> On Tue, Sep 17, 2019 at 6:15 PM Manuel Valera via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> Hello, petsc users,<br>
> <br>
> I have integrated the TS routines in my code, but i just noticed i didn't do it optimally. I was using 3 different TS objects to integrate velocities, temperature and salinity, and it works but only for small DTs. I suspect the intermediate Runge-Kutta states are unphased and this creates the discrepancy for broader time steps, so I need to integrate the 3 quantities in the same routine. <br>
> <br>
> I tried to do this by using a 5 DOF distributed array for the RHS, where I store the velocities in the first 3 and then Temperature and Salinity in the rest. The problem is that I use a staggered grid and T,S are located in a different DA layout than the velocities. This is creating problems for me since I can't find a way to communicate the information from the result of the TS integration back to the respective DAs of each variable.<br>
> <br>
> Is there a way to communicate across DAs? or can you suggest an alternative solution to this problem?<br>
> <br>
> If you have a staggered discretization on a structured grid, I would recommend checking out DMStag.<br>
> <br>
>   Thanks,<br>
> <br>
>      MAtt<br>
>  <br>
> Thanks,<br>
> <br>
> <br>
> <br>
> -- <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<br>
> <br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-8104510328263684282gmail-m_-9028655319317191149gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>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><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>