<div dir="ltr">Hi,<div><br></div><div>May I know if this change will appear in petsc-devel soon? We are trying to interface Petsc to a proprietary direct solver package. If we should expect the change soon, we may consider push back the plan a little bit. Thank you.</div>
<div><br></div><div>regards,</div><div>shenchen</div><div><br><div class="gmail_quote">On Tue, Aug 12, 2008 at 12:40 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">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;"><br>
   Mat in PETSc is actually a short hand notation for "Linear transformation"<br>
<a href="http://en.wikipedia.org/wiki/Linear_transformation" target="_blank">http://en.wikipedia.org/wiki/Linear_transformation</a>. Essentially the only<br>
operation defined by a linear transformation is A*x. Matrices are simply one<br>
way of representing finite dimensional linear transformations. So a<br>
Mat is suppose to ALWAYS provide a MatMult() everything else is optional :-).<br>
<br>
  Now you can certainly say that we should have called linear transformations<br>
in PETSc something like: LT or LinearTrans or many other things. We chose<br>
Mat since almost everyone understands linear transformations as matrices so<br>
we do not need to provide a high-falutin explanation of LT that would simply<br>
alienate and scare most potential users. Everyone thinks they understand<br>
Mat immediately.<br>
<br>
<br>
   Now back to the issue at hand. You had a very valid point in the previous<br>
email: for a factored matrix if we define MatMult() as the triangular solves<br>
then the factored matrix defines a linear transformation (whose representation<br>
is not simply a two dimensional array, but is slightly more complicated beast).<br>
So we could define a MATFACTOR as a new Mat object, like MatMFFD is<br>
a Mat object and then subclass the various packages factors undernether<br>
it.<br><font color="#888888">
<br>
   Barry</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
<br>
<br>
<br>
On Aug 11, 2008, at 9:11 AM, Lisandro Dalcin wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Aug 8, 2008 at 2:01 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  This is just at hack to avoid so many changes in PETSc.<br>
MatMFFD is truly a matrix (it has matrix vector product).<br>
</blockquote>
<br>
Well, I'm not so sure about that. Do it has MatSetValues() ?<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Barry<br>
<br>
On Aug 8, 2008, at 8:23 AM, Lisandro Dalcin wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Barry, after thinking a bit more, I believe I've found an approach<br>
that is not so radical.<br>
<br>
Why not to follow the approach for MatMFFD? That is, introduce a new<br>
matrix type, instead of a brand new object type. Let me call this new<br>
matrix type MATFACTOR. This new matrix type contains a hidden<br>
PetscObject, and that object is filled with appropriate methods<br>
depending on the MatSolverPackage.<br>
<br>
This new way will not introduce a new object type in the user-level<br>
API. An I believe that we will still simplify the code. Now a MatSolve<br>
in a MATSEQAIJ matrix will fail just because it will not have the<br>
operation filled in the 'virtual table'. MATFACTOR will fill the<br>
MatXXXFactor{Symbolic/Numeric} options in the vtable, but it will not<br>
fill things like MatMult and MatSetValues. This way, we will not need<br>
any more to 'check' if a standard matrix type like SEQAIJ, MPIAIJ, etc<br>
are or are not factored (and perhaps we can handle dense matrices in a<br>
special way, just because inplace factorizations do really make<br>
sense). So the all the 'mat->factor' checks can finally go away!<br>
<br>
What do you think?<br>
<br>
<br>
<br>
<br>
On Thu, Aug 7, 2008 at 5:05 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jul 25, 2008, at 5:47 PM, Lisandro Dalcin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
BTW, Have you ever considered the posibility of not using the 'Mat'<br>
class for factored matrices?? I believe that normal matrices and<br>
factored matrices share very few in common as to being instances of<br>
the same class. Looking at the source code in src/mat, there are many<br>
checks like 'if (mat-->factor)' or  'if (!mat->factor)' that seems to<br>
support my concern. What do you think?<br>
<br>
</blockquote>
After a (tiny) bit more thought I think we really should make this<br>
change:<br>
<br>
pros<br>
1) it will simplify the code a good amount hence less bugs<br>
2) conceptually it makes sense<br>
cons<br>
1) requires a large reorganization of the Mat code (will introduce bugs)<br>
2) requires the user to deal with one more PETSc object (MatFactor)<br>
 But since most users deal with SNES/KSP/PC most users will<br>
 never see this new object.<br>
<br>
The question is when/how to make this massive change. It is as big<br>
or bigger than the change I already made with MatGetFactor().<br>
<br>
Barry<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Fri, Jul 25, 2008 at 7:02 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
petsc-dev users,<br>
<br>
I have finally completed my changes to PETSc for a new approach to<br>
accessing external direct solvers<br>
in PETSc like Spooles, MUMPS etc. I will be pushing it to petsc-dev<br>
sometime<br>
the middle of next week.<br>
If you are using the direct solvers you might consider cloning from<br>
<br>
<a href="http://petsc.cs.iit.edu/hg/petsc/petsc-dev-new-solvers" target="_blank">http://petsc.cs.iit.edu/hg/petsc/petsc-dev-new-solvers</a>  or<br>
<br>
ssh://<a href="http://petsc@petsc.cs.iit.edu//hg/petsc/petsc-dev-new-solvers" target="_blank">petsc@petsc.cs.iit.edu//hg/petsc/petsc-dev-new-solvers</a><br>
<br>
and trying it out before then. Please report problem to<br>
<a href="mailto:petsc-maint@mcs.anl.gov" target="_blank">petsc-maint@mcs.anl.gov</a> as you hit them.<br>
<br>
<br>
Barry<br>
<br>
From the changes file<br>
<br>
The "parallel direct solver" matrix types like<br>
MATAIJSPOOLES are ALL gone. Now you use -pc_factor_mat_solver_package<br>
spooles etc or PCFactorSetMatSolverPackage() or if working directly<br>
with<br>
matrices, MatGetFactor(A,MATSPOOLES,...)<br>
<br>
<br>
</blockquote>
<br>
<br>
<br>
--<br>
Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<br>
--<br>
Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>