<div dir="ltr"><div>To make things easier, I created a simple example here:</div><div><br></div><a href="https://drive.google.com/file/d/0BxEfb1tasJxhOHJWbVJ0ZGl0LTA/view?usp=sharing">https://drive.google.com/file/d/0BxEfb1tasJxhOHJWbVJ0ZGl0LTA/view?usp=sharing</a><br><div><br></div><div>./exe -snes_newtonls okay.</div><div>./exe -snes_nasm -da_grid_z 2 okay</div><div>./exe -snes_nasm failed. It got trapped in the while loop.</div><div><br></div><div>Do you have any suggestions to avoid this trap for nz=1?</div><div><br></div><div>Thanks.</div><div><br></div><div>Xiangdong</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 29, 2016 at 11:23 AM, Xiangdong <span dir="ltr"><<a href="mailto:epscodes@gmail.com" target="_blank">epscodes@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">The code got trapped in a while loop when I switch to s=2.<div><br></div><div><a href="http://www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/da/dadd.c.html" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/da/dadd.c.html</a><br></div><div><br></div><div>In dadd.c line 85-96 </div><div>/* gone out of processor range on y axis */</div><div> 86: while(jj > ne-1 || jj < ns) {</div><div> 87: if (nr == n-1) {</div><div> 88: ns = 0;</div><div> 89: ne = ly[0];</div><div> 90: nr = 0;</div><div> 91: } else {</div><div> 92: nr++;</div><div> 93: ns = ne;</div><div> 94: ne += ly[nr];</div><div> 95: }</div><div> 96: }</div><div><br></div><div>For my case nx=5,ny=5,nz=1,s=2, np=2, snes_type nasm, the code is trapped in the loop for jj=-1, ns=0, nr=0, n=1. This negative jj comes from the line 340-349 of same file.</div><div><br></div><div><div>/* global and subdomain ISes for the local indices of the subdomain */</div><div>341: /* todo - make this not loop over at nonperiodic boundaries, which will be more involved */</div><div>342: lower.i = subinfo.gxs;</div><div>343: lower.j = subinfo.gys;</div><div>344: lower.k = subinfo.gzs;</div><div>345: upper.i = subinfo.gxs+subinfo.gxm;</div><div>346: upper.j = subinfo.gys+subinfo.gym;</div><div>347: upper.k = subinfo.gzs+subinfo.gzm;</div><div><br></div><div>349: DMDACreatePatchIS(dm,&lower,&upper,&gdis);</div></div><div><br></div><div>When trapped, subinfo.gxs=-2. Since there is a todo comment, I am not sure this is the reason for the while loop trap.<br></div><div><br></div><div>Thanks.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Xiangdong</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 5:16 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
If you make the stencil width as wide at the overlap does the problem go away and you get expected convergence?<br>
<div><div><br>
> On Jun 28, 2016, at 3:48 PM, Xiangdong <<a href="mailto:epscodes@gmail.com" target="_blank">epscodes@gmail.com</a>> wrote:<br>
><br>
> Let me illustrate my point and question by an example. I have a 1d nonlinear problem with Nx=5 and stencil width 1. When I run it with np=2, processor 1 own cells 1,2,3 (+ ghost 4) and processor 2 own cells 4,5 (+ ghost 3). I also have functions FormFunctionLocal and FormJacobianLocal to compute the residual and Jacobian.<br>
><br>
> i) snes_type newtonls. The Jacobian is in mpiaij format distributed on two processors. processor 1 computes the first three rows of Jac (size 3x5) and processor 1 computes the last two rows of Jac (size 2x5). The code works fine.<br>
><br>
> ii) snes_type nasm and da_overlap 0. Each processor has its own Jac (seqaij). Processor 1 computes its 3x3 Jac and Processor 2 computes its 2x2 Jac. The code works fine.<br>
><br>
> iii) snes_type nasm and da_overlap 1. Each processor needs to computes its own Jac. Processor 1 computes its 4x4 Jac and Processor 2 computes its 3x3 Jac. However, for processor 1 to compute the 4-th row of its Jac, it needs the properties information stored on cell 5, which is not available on processor 1. The zero pivot error is from this wrong Jac for the row corresponding to the overlap cell. The mat_fd_color does not work either for the same reason that information from cell 5 is not available on processor 1.<br>
><br>
> Do you have any suggestion for the overlap case? Thank you.<br>
><br>
> Best,<br>
> Xiangdong<br>
><br>
> On Mon, Jun 27, 2016 at 4:21 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Jun 27, 2016, at 3:15 PM, Xiangdong <<a href="mailto:epscodes@gmail.com" target="_blank">epscodes@gmail.com</a>> wrote:<br>
> ><br>
> > Hello everyone,<br>
> ><br>
> > I am trying different number of da_overlap to see its effects on nasm and aspin preconditioner. The codes works fine with -da_overlap 0. However, when I change the option -da_overlap 1, it crashed with the error message like "zero pivot row 12544 value 0 tolerance 2.2e-14". The option -pc_factor_nonzeros_along_diagonal does not fix this zero pivot issue.<br>
> ><br>
> > Do you have any quick suggestions for me to try to fix this issue?<br>
><br>
> My guess is that it is bug in the da_overlap business or in the example; normally I would not expect this to happen. Is this a PETSc example I can run (tell me example and exact options) to reproduce the problem?<br>
><br>
> Thanks<br>
><br>
> Barry<br>
><br>
> ><br>
> > Thank you.<br>
> ><br>
> > Best,<br>
> > Xiangdong<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>