<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>All public API changes have to be documented at src/docs/website/documentation/changes/dev.html.</div>
<div><br></div><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/a942f19a37c9" target="_blank">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/a942f19a37c9</a><div>
<br></div></blockquote><div><br>Sorry, I didn't know that. A stupid question but, can you say how many users are using MATIS objects?<br><br></div><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><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>
<br></div><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><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><br></div><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><br>MATIS were already forced to be square before I began using it.<br><br><br></div></div>Pushed a fix to the problems you highlighted <br>
<br><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/93e67397a066">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/93e67397a066</a><br><br>Calling MatSetBlockSize before MatSetSizes in MatCreateIS solved all my  problems.<br>
<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?<br clear="all">
<br><br>-- <br>Stefano<br>