<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 6:33 AM, Sander Land <span dir="ltr"><<a href="mailto:sander.land@gmail.com" target="_blank">sander.land@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"><div>Yes, I figured I'd need to rewrite my dirichlet bc implementation to zero out the row rather than remove the dof completely. For now I'm just avoiding partial bcs.<br>Using MatSetBlockSize is a problem because the matrix has stuff after the xyzxyz (hydrostatic pressure dofs and a few coupled things). MatGetSubMatrix inherits the block size of 1, and I can't change it afterwards.</div></div></blockquote><div><br></div><div>Humm, this needs to work. Are you saying you get the (sub) matrix with an IS of the non-pressure part? You should be able to set that block size to 3. If this get submatrix happens inside of FieldSplit then I think there is a solution for this.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Sander<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 12:26 AM, Mark Adams <span dir="ltr"><<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</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">Note, you want to tell the matrix that it has these blocks with MatSetBlockSize, and do not remove a single DOF (like for BCs). That is, xyzxyxyz is not allowed. The block size is critical for GAMG and would think HYPRE uses it also because it does OK on elasticity.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 15, 2015 at 2:52 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"><span><br>
> On Jul 15, 2015, at 5:43 AM, Sander Land <<a href="mailto:sander.land@gmail.com" target="_blank">sander.land@gmail.com</a>> wrote:<br>
><br>
> Hi Barry,<br>
><br>
> I have some structures set up that map dofs to their respective matrix indices, and it wasn't difficult to change them.<br>
><br>
> However, now this call:<br>
> MatMultAdd(ctxp->B,xp,bx,xxtmp);<br>
> is directed to "MatMultAdd_SeqAIJ_Inode" and gives a vector lock error at line 601 of mat/impls/aij/seq/inode.c<br>
> ierr = VecGetArray(zz,&z);<br>
> I think this is a bug and should be VecGetArrayRead as it doesn't need to be written to.<br>
<br>
</span> Oh yes, this is a bug. I have fixed it in maint, master and next<br>
<span>><br>
> In the old xxxyyyzzz ordering this call went to MatMultAdd_SeqAIJ, which (via VecGetArrayPair) does use VecGetArrayRead. I'm not sure what is causing the different matrix formats.<br>
<br>
</span> When the values are interlaced the matrix has "identical nodes" (i-nodes) which means certain rows have identical nonzero structure with there neighbors and the AIJ matrix code automatically switches to the more efficient Inode operations. This is why you only saw the bug with interlacing.<br>
<div><div>><br>
> I'm also still not sure at what point I can change the matrix block size to get the correct BoomerAMGSetNumFunctions.<br>
><br>
> Thanks,<br>
> Sander<br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Jul 14, 2015 at 6:34 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Jul 14, 2015, at 11:37 AM, Sander Land <<a href="mailto:sander.land@gmail.com" target="_blank">sander.land@gmail.com</a>> wrote:<br>
> ><br>
> > Hi Matt,<br>
> ><br>
> > Doing things to the PC like this has worked for me for a long time. It just happened to be formerly KSPPREONLY/PCLU. Setting things like GMRES/PCNONE works as well with no errors, though it converges far too slowly.<br>
> ><br>
> > The actual preconditioner I am trying to form is one from recent literature and uses a slightly modified Schur complement split embedded in another Schur complement split with multiple solves of the inner system and very specific choices for sub-preconditioners. I don't think command line options will work very well here.<br>
> ><br>
> > I've since gone the way of just using PCSHELL and setting things up more explicitly. This seems to work, but i'm not quite sure how to set up boomeramg for one of the sub-problems.<br>
> ><br>
> > boomeramg is used on the matrix A derived from:<br>
> > MatGetSubMatrix(J,is_x ,is_x ,MAT_INITIAL_MATRIX,&ctxp->A);<br>
> > The degrees of freedom for J are xxxyyyzzzpw, with the size of xxxyyyzzz around 20k, p around 1k, and w 8 for my 'small' test problem.<br>
> ><br>
> > I can see that HYPRE_BoomerAMGSetNumFunctions takes its value from the matrix block size. This is 1 for J as it doesn't have a consistent block size. However, the number of functions for boomeramg should be 3.<br>
> > Changing the block size is not allowed by petsc, and there doesn't seem to be another way to reach HYPRE_BoomerAMGSetNumFunctions.<br>
> > What is the best way to handle this, and does it matter that the dofs are ordererd xxxyyyzzz rather than xyzxyzxyz ?<br>
><br>
> I don't think BoomerAMG supports xxxyyyzzz, I think it will just get very confused trying to do algebraic multigrid with this form. Read up on it but my guess is you need to rewrite the code that prepares the system to do the interlacing.<br>
><br>
> Barry<br>
><br>
> ><br>
> ><br>
> > Thanks,<br>
> > Sander<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Jul 10, 2015 at 7:44 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
> > On Tue, Jun 30, 2015 at 3:10 PM, Sander Land <<a href="mailto:sander.land@gmail.com" target="_blank">sander.land@gmail.com</a>> wrote:<br>
> > This gives<br>
> > [0]PETSC ERROR: Object is in wrong state<br>
> > [0]PETSC ERROR: Matrix must be set first<br>
> ><br>
> > The PC is from a SNESGetKSP, and I have called SNESSetJacobian before this.<br>
> ><br>
> > If this is embedded in a SNES, it is very messy to yank it out and do thing manually. However, if you<br>
> > set the matrix in the PC manually, it might work.<br>
> ><br>
> > However, I would encourage you to try an alternate scheme and see if you think it is easier. We have<br>
> > started to use the DM object to hold this kind of information. For FieldSplit, I think it is easier to tell<br>
> > a DMShell about your field division, and then have it pass this on to PCFIELDSPLIT. So you would<br>
> ><br>
> > a) Create a DMSHELL<br>
> ><br>
> > b) Create a PetscSection and call DMSetDefaultSection()<br>
> ><br>
> > c) Call SNESSetDM()<br>
> ><br>
> > d) use command line options to configure the split -pc_fieldsplit_0_fields 0 -pc_fieldsplit_1_fields 1<br>
> ><br>
> > Then everything should work, and can work in any embedded context. Does this make sense?<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Matt<br>
> ><br>
> > Thanks,<br>
> > Sander<br>
> ><br>
> > On Tue, Jun 30, 2015 at 2:09 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
> > On Tue, Jun 30, 2015 at 11:43 AM, Sander Land <<a href="mailto:sander.land@gmail.com" target="_blank">sander.land@gmail.com</a>> wrote:<br>
> > I am trying to use the Schur complement preconditioner in petsc, but am encountering a null argument error calling PCFieldSplitGetSubKSP.<br>
> > This only happens on PC_COMPOSITE_SCHUR, the multiplicative/additive options do return a KSP array.<br>
> ><br>
> > Error message:<br>
> ><br>
> > [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------<br>
> > [0]PETSC ERROR: Null argument, when expecting valid pointer<br>
> > [0]PETSC ERROR: Null Object: Parameter # 1<br>
> > [0]PETSC ERROR: See <a href="http://www.mcs.anl.gov/petsc/documentation/faq.html" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/documentation/faq.html</a> for trouble shooting.<br>
> > [0]PETSC ERROR: Petsc Release Version 3.6.0, Jun, 09, 2015<br>
> > [0]PETSC ERROR: ./elecmech on a arch-linux2-cxx-debug<br>
> > [0]PETSC ERROR: Configure options --with-shared-libraries=1 --with-debugging=1 --download-openmpi=1 --with-clanguage=c++ --download-fblaslapack=1 --download-scalapack=1 --download-blacs=1 --download-suitesparse=1 --download-pastix=1 --download-superlu=1 --dowload-essl=1 --download-ptscotch=1 --download-mumps=1 --download-lusol=1<br>
> > [0]PETSC ERROR: #1 MatSchurComplementGetKSP() line 317 in petsc-3.6/src/ksp/ksp/utils/schurm.c<br>
> > [0]PETSC ERROR: #2 PCFieldSplitGetSubKSP_FieldSplit_Schur() line 1264 in petsc-3.6/src/ksp/pc/impls/fieldsplit/fieldsplit.c<br>
> > [0]PETSC ERROR: #3 PCFieldSplitGetSubKSP() line 1668 in petsc-3.6/src/ksp/pc/impls/fieldsplit/fieldsplit.c<br>
> ><br>
> > Code snippet:<br>
> ><br>
> > ISCreateGeneral(PETSC_COMM_SELF,xp_dofs,&ii[0],PETSC_COPY_VALUES,&is_xp);<br>
> > ISCreateGeneral(PETSC_COMM_SELF,all_dofs - xp_dofs,&ii[xp_dofs],PETSC_COPY_VALUES,&is_wk);<br>
> ><br>
> > PCSetType(pc,PCFIELDSPLIT);<br>
> > PCFieldSplitSetType(pc,PC_COMPOSITE_SCHUR);<br>
> > PCFieldSplitSetIS(pc,"xp",is_xp);<br>
> > PCFieldSplitSetIS(pc,"wk",is_wk);<br>
> > int n;<br>
> > KSP* ksps;<br>
> > PC subpc;<br>
> > PCFieldSplitGetSubKSP(pc,&n,&ksps);<br>
> ><br>
> ><br>
> > ii here is simply an array with ii[i] = i. There is probably a better way to simply indicate two blocks of different size, but I couldn't find it.<br>
> ><br>
> > It looks like the PC is not setup. Can you try calling PCSetUp(pc) before GetSubKSP()?<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Matt<br>
> ><br>
> > Thanks,<br>
> > Sander<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>
> ><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>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>