<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 3:33 PM Boris Boutkov <<a href="mailto:borisbou@buffalo.edu">borisbou@buffalo.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thank you for the reply. I think Ive made a little progress but still have lingering issues regarding this situation. <br></div><div><br></div><div>My misunderstanding earlier came from the fact that when I was using DMCreateFieldIS inside of my DMCreateInterpolation in order to extract the sub-projection-matrix, the returned fields from DMCreateFieldIS corresponded to individual fields which I was not unioning at the time. Adding a call to ISSum on the returned fields alleviated this issue and so I was able to extract a submatrix of proper row size. The issue that remains is that the coarse DM coming to me inside DMCreateInterpolation has 3 fields while the fine has the expected 2 [in the context of the 2D (u,v,p) Stokes vars with a split to do GMG on the velocity block]. This issue is similar if I do GMG with 3 MG levels, the fine DM has 2 fields, while the other two coarser levels have 3 fields. It seems like coarser DMs are not properly fieldsplit by the time I have access to them in DMCreateInterpolation and this leads to incompatible sizes in the Galerkin product. So I guess my question becomes: am I expected to do the field decompositions for coarser DMs at this stage inside of my DMCreateInterpolation, or is this something that should be occurring during an earlier setup phase.</div></div></blockquote><div><br></div><div>Okay, that sounds like a bug. I have to look at this anyway, since I need GMG to work for Stokes. It already does, but</div><div>now maybe that is by accident. Looking at my code, it only reads field info from the fine grid, so it would work as long as</div><div>the field numbering remains the same, which it does in Stokes.</div><div><br></div><div>I will try and look at this tomorrow.</div><div><br></div><div> Thanks,</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 dir="ltr"><div>Thanks again for the help,</div><div>- Boris<br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 8:21 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 12:23 PM Boris Boutkov <<a href="mailto:borisbou@buffalo.edu" target="_blank">borisbou@buffalo.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Hello again all,<br><br></div>I've been trying to get GMG+FS to work with an external DMShell provided by libMesh, see for reference <a href="https://www.mail-archive.com/petsc-dev@mcs.anl.gov/msg23497.html" target="_blank">https://www.mail-archive.com/petsc-dev@mcs.anl.gov/msg23497.html</a> .<br></div><br></div><div>The situation is that while I've managed to successfully attach some extra hooks to CreateSubDM_Shell to set appropriate interpolation, restriction, and a few other operators that I call, I now encounter matrix multiplication size mismatches when computing the Galerkin triple product to produce the coarser operators during the MG setup. As it stands, libMesh is computing a global projection matrix and I was hoping to be able to extract sub matrices out of it corresponding to the various fields but am not sure about the right way to go about this.<br><br></div><div>Since we are using DMShell and provide Section information I was hoping to use something along the lines of MatCreateSubmatrix and extract from the global projection Mat, only projections corresponding to the fields in question. Doing this seems to entail the need to provide the row and column ISs. </div></div></div></div></div></blockquote><div><br></div><div>Yes, that is right. You just need the ISes.</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 dir="ltr"><div dir="ltr"><div dir="ltr"><div>While I can extract Index Set lists from the incoming DMs during DMCreateInterpolation via DMCreateFieldIS, I'm not sure what the right way to extract the row and column information from these IS would be. Is there a natural way to achieve such a thing from PETSc's side or am I going about this in the completely wrong way and need to construct field based projections from my end?<br></div></div></div></div></div></blockquote><div><br></div><div>I am not sure what is being asked. Your hooks are transfered during DMCreateSubDM(). It creates the IS for the subfield, so at that point you know it. Either store that or use it right there to extract your interpolation.</div><div><br></div><div> Thanks,</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 dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div><div>Thanks as always for any information you can provide, <br></div><div>- Boris<br></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_909378329775228693m_-8972863868433356999gmail_signature" data-smartmail="gmail_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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_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>