<div class="gmail_quote">On Tue, May 8, 2012 at 3:30 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 class="gmail_quote"><div>Sorry, I didn't know that. A stupid question but, can you say how many users are using MATIS objects?<br></div></div></blockquote><div><br></div><div>I don't know, probably not a great number, but enough that it has to be documented.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div></div><div>2. What was wrong with the default MatGetVecs()?</div>
<div><br></div></blockquote></div><div><br>There's a conceptual difference: default MatGetVecs uses mat->rmap->n and mat->cmat->n as local sizes of the vectors since it assumes a distributed Matrix. MATIS object is not distributed in a standard way (say, all mat->rmap->n values sums to number of global rows), MatMult_IS is not directly performed using the local part of the global vector, thus there is not a real need (apart of Petsc checking the sizes) of the notion of mat->rmap->n (or mat->cmap->n) as in the standard implementation. What you really need is the global size of the vector; indeed the sizes of the local vectors used to perform MatMult_IS doesn't sum up to the vector global size.<br>
</div></div></blockquote><div><br></div><div>PetscLayout and the matrix size statements don't work as you describe here; if they do somewhere, it's broken. The matrix sizes are really statements about the distribution of the _vector_ that the matrix multiplies against and produces. With *AIJ, that happens to also be the row partition, and the off-diagonal part is managed in a compatible way, but that is not required. For dense matrices, it might make sense to store the matrix with an entirely different distribution (e.g. cyclic). An implementation issue like the sizes of the local matrices in MATIS should _not_ change the global matrix size (rmap and cmap).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>3. Options prefixes should inherit the prefix from the parent and should end with "_" so that they aren't squashed together with the suboptions.</div>

</blockquote></div><div><br>Since MatSetOptionsPrefix(is->A,"is") was already there, I thought it was right using the same prefix for local vectors. Change it as you prefer.<br></div></div></blockquote><div>
<br></div><div>Ah, okay. It should be done like this in the future.</div><div><br></div><div><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/b70fc058783a">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/b70fc058783a</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div><br></div><div>5. Why is the matrix being forced to be square?</div><div><br></div></blockquote></div><div><br>MATIS were already forced to be square before I began using it.<br></div></div></blockquote><div><br></div>
<div>Okay, I just hate adding more places where such unnecessary constraints are codified.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div></div></div>Pushed a fix to the problems you highlighted <br>
<br><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/93e67397a066" target="_blank">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/93e67397a066</a><br><br>Calling MatSetBlockSize before MatSetSizes in MatCreateIS solved all my  problems.<br>
</blockquote><div><br></div><div>Great, thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Since we are speaking about MATIS. In my codes, I have a function (now it is in Fortran but I can translate it)<br><br>MatISOptimize(Mat A,IS *LocalIS ,IS *GlobalIS)<br><br>which changes the MATIS object, changing its local to global mapping to optimize either for local scatters and for global communications costs. It also changes the local matrix associated to the MATIS object. The function also returns the permutations used (if not PETSC_NULL). Can I add it to matis.c? Since it changes the underlying object, what are the requirements of PETSc? Should the user be able to insert the values with the original ordering? Any suggestions?</blockquote>
</div><br><div>MatSetValues() is fine since only the global ordering is used. MatSetValuesLocal() would ideally continue to work with the old local space because the user has to redistribute their mesh to use the new ordering (maybe there should be a translation filter).</div>
<div><br></div><div>But how does this function actually work? Can the subdomain boundaries move, or are subdomains just moved to a different process?</div><div><br></div><div><br></div><div>For a different, but related algorithm, I'm considering writing a MatPA (PA = partially assembled) which would choose some points to assemble internally. The reason for storing in partially assembled form is that I will want to solve a number of pinned Neumann problems to determine the coarse space and I'd rather not have to take unnecessary submatrices. Do you think this is a bad idea and I should just use MatIS? (I also want support for multiple subdomains per process and multiple processes per subdomain, though that could be added to MatIS.)</div>