August 2008 - petsc-dev - mailman3.cels.anl.gov

Re: Is c2html a required external package?
by Satish Balay 08 Aug '08

08 Aug '08

I suspect c2html does not compile with IBM compilers. We should support --with-c2html=0 option. Satish On Fri, 8 Aug 2008, Matthew Knepley wrote: > On Fri, Aug 8, 2008 at 12:09 AM, Shi Jin <jinzishuai(a)yahoo.com> wrote: > > Hi there, > > > > I was trying to build petsc-dev on a IBM AIX but failed at c2html. I tried not to use it with --with-c2html=0 but it seemed still be needed. Why do we need it? I don't need to generate documentations for this test. > > Thanks. > > It is for documentation, but we do not consider an installation with > broken documentation fully functional. Can you send > the configure.log? > > Thanks, > > Matt > > > Shi > > > > -- > > Shi Jin, PhD >

1 0

Re: New approach for external direct solvers in PETSc
by Lisandro Dalcin 08 Aug '08

08 Aug '08

Barry, after thinking a bit more, I believe I've found an approach that is not so radical. Why not to follow the approach for MatMFFD? That is, introduce a new matrix type, instead of a brand new object type. Let me call this new matrix type MATFACTOR. This new matrix type contains a hidden PetscObject, and that object is filled with appropriate methods depending on the MatSolverPackage. This new way will not introduce a new object type in the user-level API. An I believe that we will still simplify the code. Now a MatSolve in a MATSEQAIJ matrix will fail just because it will not have the operation filled in the 'virtual table'. MATFACTOR will fill the MatXXXFactor{Symbolic/Numeric} options in the vtable, but it will not fill things like MatMult and MatSetValues. This way, we will not need any more to 'check' if a standard matrix type like SEQAIJ, MPIAIJ, etc are or are not factored (and perhaps we can handle dense matrices in a special way, just because inplace factorizations do really make sense). So the all the 'mat->factor' checks can finally go away! What do you think? On Thu, Aug 7, 2008 at 5:05 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Jul 25, 2008, at 5:47 PM, Lisandro Dalcin wrote: >> >> BTW, Have you ever considered the posibility of not using the 'Mat' >> class for factored matrices?? I believe that normal matrices and >> factored matrices share very few in common as to being instances of >> the same class. Looking at the source code in src/mat, there are many >> checks like 'if (mat-->factor)' or 'if (!mat->factor)' that seems to >> support my concern. What do you think? >> > After a (tiny) bit more thought I think we really should make this change: > > pros > 1) it will simplify the code a good amount hence less bugs > 2) conceptually it makes sense > cons > 1) requires a large reorganization of the Mat code (will introduce bugs) > 2) requires the user to deal with one more PETSc object (MatFactor) > But since most users deal with SNES/KSP/PC most users will > never see this new object. > > The question is when/how to make this massive change. It is as big > or bigger than the change I already made with MatGetFactor(). > > Barry > > > >> >> >> On Fri, Jul 25, 2008 at 7:02 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>> petsc-dev users, >>> >>> I have finally completed my changes to PETSc for a new approach to >>> accessing external direct solvers >>> in PETSc like Spooles, MUMPS etc. I will be pushing it to petsc-dev >>> sometime >>> the middle of next week. >>> If you are using the direct solvers you might consider cloning from >>> >>> http://petsc.cs.iit.edu/hg/petsc/petsc-dev-new-solvers or >>> >>> ssh://[email protected]//hg/petsc/petsc-dev-new-solvers >>> >>> and trying it out before then. Please report problem to >>> petsc-maint(a)mcs.anl.gov as you hit them. >>> >>> >>> Barry >>> >>> From the changes file >>> >>> The "parallel direct solver" matrix types like >>> MATAIJSPOOLES are ALL gone. Now you use -pc_factor_mat_solver_package >>> spooles etc or PCFactorSetMatSolverPackage() or if working directly with >>> matrices, MatGetFactor(A,MATSPOOLES,...) >>> >>> >> >> >> >> -- >> Lisandro Dalcï¿½n >> --------------- >> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) >> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) >> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >> Tel/Fax: +54-(0)342-451.1594 >> > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: Is c2html a required external package?
by Matthew Knepley 08 Aug '08

08 Aug '08

On Fri, Aug 8, 2008 at 12:09 AM, Shi Jin <jinzishuai(a)yahoo.com> wrote: > Hi there, > > I was trying to build petsc-dev on a IBM AIX but failed at c2html. I tried not to use it with --with-c2html=0 but it seemed still be needed. Why do we need it? I don't need to generate documentations for this test. > Thanks. It is for documentation, but we do not consider an installation with broken documentation fully functional. Can you send the configure.log? Thanks, Matt > Shi > > -- > Shi Jin, PhD -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Is c2html a required external package?
by Shi Jin 08 Aug '08

08 Aug '08

Hi there, I was trying to build petsc-dev on a IBM AIX but failed at c2html. I tried not to use it with --with-c2html=0 but it seemed still be needed. Why do we need it? I don't need to generate documentations for this test. Thanks. Shi -- Shi Jin, PhD

1 0

Re: New approach for external direct solvers in PETSc
by Lisandro Dalcin 07 Aug '08

07 Aug '08

On Thu, Aug 7, 2008 at 5:05 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> > After a (tiny) bit more thought I think we really should make this change: Well, very good news! > cons > 1) requires a large reorganization of the Mat code (will introduce bugs) > 2) requires the user to deal with one more PETSc object (MatFactor) > But since most users deal with SNES/KSP/PC most users will > never see this new object. Regarding (1) I believe we will end-up with a code having less bugs than the current one. Regarding (2), even in the case a user wants to handle by himself the factorizations outside of KSP/PC, the new object will be not too hard to use, as it user interface will be not too large. > The question is when/how to make this massive change. It is as big > or bigger than the change I already made with MatGetFactor(). > Well, we can start this in a separate branch. And I'll definitively help you with all this. >> >> On Fri, Jul 25, 2008 at 7:02 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>> petsc-dev users, >>> >>> I have finally completed my changes to PETSc for a new approach to >>> accessing external direct solvers >>> in PETSc like Spooles, MUMPS etc. I will be pushing it to petsc-dev >>> sometime >>> the middle of next week. >>> If you are using the direct solvers you might consider cloning from >>> >>> http://petsc.cs.iit.edu/hg/petsc/petsc-dev-new-solvers or >>> >>> ssh://[email protected]//hg/petsc/petsc-dev-new-solvers >>> >>> and trying it out before then. Please report problem to >>> petsc-maint(a)mcs.anl.gov as you hit them. >>> >>> >>> Barry >>> >>> From the changes file >>> >>> The "parallel direct solver" matrix types like >>> MATAIJSPOOLES are ALL gone. Now you use -pc_factor_mat_solver_package >>> spooles etc or PCFactorSetMatSolverPackage() or if working directly with >>> matrices, MatGetFactor(A,MATSPOOLES,...) >>> >>> >> >> >> >> -- >> Lisandro Dalcï¿½n >> --------------- >> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) >> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) >> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >> Tel/Fax: +54-(0)342-451.1594 >> > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: New approach for external direct solvers in PETSc
by Barry Smith 07 Aug '08

07 Aug '08

On Jul 25, 2008, at 5:47 PM, Lisandro Dalcin wrote: > > BTW, Have you ever considered the posibility of not using the 'Mat' > class for factored matrices?? I believe that normal matrices and > factored matrices share very few in common as to being instances of > the same class. Looking at the source code in src/mat, there are many > checks like 'if (mat-->factor)' or 'if (!mat->factor)' that seems to > support my concern. What do you think? > After a (tiny) bit more thought I think we really should make this change: pros 1) it will simplify the code a good amount hence less bugs 2) conceptually it makes sense cons 1) requires a large reorganization of the Mat code (will introduce bugs) 2) requires the user to deal with one more PETSc object (MatFactor) But since most users deal with SNES/KSP/PC most users will never see this new object. The question is when/how to make this massive change. It is as big or bigger than the change I already made with MatGetFactor(). Barry > > > On Fri, Jul 25, 2008 at 7:02 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> >> petsc-dev users, >> >> I have finally completed my changes to PETSc for a new approach to >> accessing external direct solvers >> in PETSc like Spooles, MUMPS etc. I will be pushing it to petsc-dev >> sometime >> the middle of next week. >> If you are using the direct solvers you might consider cloning from >> >> http://petsc.cs.iit.edu/hg/petsc/petsc-dev-new-solvers or >> >> ssh://[email protected]//hg/petsc/petsc-dev-new-solvers >> >> and trying it out before then. Please report problem to >> petsc-maint(a)mcs.anl.gov as you hit them. >> >> >> Barry >> >> From the changes file >> >> The "parallel direct solver" matrix types like >> MATAIJSPOOLES are ALL gone. Now you use -pc_factor_mat_solver_package >> spooles etc or PCFactorSetMatSolverPackage() or if working directly >> with >> matrices, MatGetFactor(A,MATSPOOLES,...) >> >> > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: first comments after reviewing and trying the new matrix factorization code
by Barry Smith 07 Aug '08

07 Aug '08

On Aug 7, 2008, at 2:24 PM, Lisandro Dalcin wrote: > I've started to wrap the functionality of the new code in petsc4py. > However, I'm detecting some inconsistencies and possible > improvements/simplifications and then I need some directions in order > to push good fixes in petsc-dev. > > Then, here is my tow first questions. > > 1) Suppose I do > > MatGetFactor(A, solver_package, factor_type, &F) > > Then, if the call is successful, the following should happen > > a) F->factor should be equal to 'factor_type' Yes. > > b) F->preallocated sould be PETSC_TRUE I guess this is ok. > > c) F->assembled sould be PETSC_TRUE Hmm, not sure, should we wait until after the numerical factorization to mark this as true? > > > Is this OK? > > > 2) What should be the output of MatView(F, viewer) ? ASCII info should print matrix size, number nonzeros and solver type. Otherwise I am fine with not printing anything and generating an unsupported viewer type or format. > > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: about accessing 'comm' and 'type_name' and others from PetscObject in new code
by Barry Smith 07 Aug '08

07 Aug '08

Guilty. I have changed them all the use the PetscObject cast you prefer. Barry As to the macros: no, never, not in a million years :-) On Aug 7, 2008, at 2:05 PM, Lisandro Dalcin wrote: > I've noticed that recent commits are now accessing PetscObject > internals like this > > obj->hdr.comm > obj->hdr.type_name > > I would really prefer to not do that, and instead use the more verbose > > ((PetscObject)obj)->comm > ((PetscObject)obj)->type_name > > If this is really disgusting, perhaps we should define and use some > (private?) macros like below. By far, 'comm', 'type_name', and > 'prefix' are the more commonly accessed members when implementeing > Vec, Mat, KSP, PC, etc. > > PetscCOMM(obj) > PetscTYPE(obj) > PetscPREFIX(obj) > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

first comments after reviewing and trying the new matrix factorization code
by Lisandro Dalcin 07 Aug '08

07 Aug '08

I've started to wrap the functionality of the new code in petsc4py. However, I'm detecting some inconsistencies and possible improvements/simplifications and then I need some directions in order to push good fixes in petsc-dev. Then, here is my tow first questions. 1) Suppose I do MatGetFactor(A, solver_package, factor_type, &F) Then, if the call is successful, the following should happen a) F->factor should be equal to 'factor_type' b) F->preallocated sould be PETSC_TRUE c) F->assembled sould be PETSC_TRUE Is this OK? 2) What should be the output of MatView(F, viewer) ? -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

about accessing 'comm' and 'type_name' and others from PetscObject in new code
by Lisandro Dalcin 07 Aug '08

07 Aug '08

I've noticed that recent commits are now accessing PetscObject internals like this obj->hdr.comm obj->hdr.type_name I would really prefer to not do that, and instead use the more verbose ((PetscObject)obj)->comm ((PetscObject)obj)->type_name If this is really disgusting, perhaps we should define and use some (private?) macros like below. By far, 'comm', 'type_name', and 'prefix' are the more commonly accessed members when implementeing Vec, Mat, KSP, PC, etc. PetscCOMM(obj) PetscTYPE(obj) PetscPREFIX(obj) -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0