<div dir="ltr">Note, I have a pull request in (for weeks) that adds a convergence study to snes/ex56 so this might conflict Stefano is doing.<div><br></div><div>Also, next is broken because of what I think was an API change from Matt <a href="http://et.al">et.al</a>.  We are getting a bit tied up here.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 14, 2016 at 11:05 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">Stefano, There is a bug, I think, that was discussed on an earlier thread and it did not get resolved AFAIK. If you feel like folding this into this project (if you page it back in) then that would be nice. Here is a quote:<div><br></div><div><div style="font-size:12.8px">My pull request for snes/ex56 has:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">ierr = VecNorm(xx,NORM_INFINITY,&mdis<wbr>p[iter]);CHKERRQ(ierr);<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">When I tried to use VecStrideNorm I got the error that <span class="m_-1225031510395381407gmail-il">block</span> <span class="m_-1225031510395381407gmail-il">size</span> was not set. You can't set it manually so I was stuck (not a big deal, but there is either a bug in Plex or a bug in the way that I am using it).</div></div><span class="HOEnZb"><font color="#888888"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Mark</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 11, 2016 at 8:54 AM, Stefano Zampini <span dir="ltr"><<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@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">Here is a first attempt: stefano_zampini/allow-late-mat<wbr>setblocksizes<div><br></div><div>The new block sizes are  not yet propagated to the diagonal and off-diagonal part.</div><div>ex56 seems to produce the same AMG hierarchy.</div></div><div class="gmail_extra"><div><div class="m_-1225031510395381407h5"><br><div class="gmail_quote">2016-10-11 9:54 GMT+03:00 Stefano Zampini <span dir="ltr"><<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
So it doesn't want to change the block size if map->range has been set (i.e. PetscLayoutSetUp()) was called. But if the matrix is AIJ so long as  !(map->n % bs) one can actually set the block size at any time. So how about if I change the Mat code to allow setting the block size late for AIJ?  Maybe we can also get rid of PCFieldSplitSetBlockSize() and a PCSPAISetBlockSize()?<br>
<br></blockquote><div><br></div></span><div>This is precisely what I was referring to as hacking. For sure MatSetBlockSize (and PetscLayoutSetBlockSize) can be patched if the bs value passed in is valid (i.e. !(map->n % bs) == 1). </div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
One issue that comes up with this change is: should setting the block size later automatically reset the block size of the two inner AIJ matrices? Or should they remain one? I could have it update the inner block sizes at the expense of a tiny bit more code. But one complication is that MatSetUpMultiply_MPIAIJ() always sets the column block size of the off-diagaonl matrix to 1; so this needs to be respected.<br>
<br></blockquote><div><br></div></span><div>I think the row block size of the inner matrices should be modified, as well as the column block size of the diagonal part.</div><div>We should write a comprehensive test that sets the block sizes after matrix setup to really understand what needs to be fixed.</div><div>I can take care of it if you wish. </div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The PETSc design policy of "there is one way to do something" dictates that it is best not to have PCSetBlockSize() unless absolutely necessary so I am trying to see if it is absolutely necessary.<br>
<span class="m_-1225031510395381407m_6501771790160055247m_-8175497307719046701gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div></span><div>I was not asking for a general PCSetBlockSize(); just for a way to customize GAMG when needed (something like HYPRE_BoomerAMGSetNumFunc<wbr>tions)</div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_-1225031510395381407m_6501771790160055247m_-8175497307719046701gmail-HOEnZb"><font color="#888888">
  Barry<br>
</font></span><div class="m_-1225031510395381407m_6501771790160055247m_-8175497307719046701gmail-HOEnZb"><div class="m_-1225031510395381407m_6501771790160055247m_-8175497307719046701gmail-h5"><br>
<br>
<br>
<br>
> On Oct 10, 2016, at 10:18 AM, Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>> wrote:<br>
><br>
> Mark,<br>
><br>
> I was wondering if you could provide an API/command line customization for PCGAMG to explicitly provide the "block size" of the problem to the gamg solver, instead of using the block size of the matrix. The matrix block size could be always used as a fallback if this new information as not been provided.<br>
><br>
> I'm interfacing a complicated finite element package to PETSc , where you cannot do any assumption on the blocksize of the problem during matrix setup, and (AFAIK) I cannot change the block size with a call to MatSetBlockSize after the matrix has been finalized without hacking (that I would like to avoid).<br>
><br>
> Thanks<br>
> --<br>
> Stefano<br>
<br>
</div></div></blockquote></span></div><span class="m_-1225031510395381407m_6501771790160055247HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-1225031510395381407m_6501771790160055247m_-8175497307719046701gmail_signature">Stefano</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_-1225031510395381407HOEnZb"><font color="#888888">-- <br><div class="m_-1225031510395381407m_6501771790160055247gmail_signature" data-smartmail="gmail_signature">Stefano</div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>