From: Jan B. <bie...@tu...> - 2008-06-17 13:09:44
|
Hi, I would like to use ILU preconditioning in parallel. Here, Petsc provides an interface to BlockSolve95 but requires the matrix format MPIBAIJ. So far MPIAIJ is standard in libmesh. Do you think I can just change the matrix format or does that cause any problems (with parmetis or whatever)? Or do you have any idea how to work arround that? Thanks, Jan |
From: John P. <jwp...@gm...> - 2008-06-17 13:22:55
|
On Tue, Jun 17, 2008 at 8:09 AM, Jan Biermann <bie...@tu...> wrote: > Hi, > I would like to use ILU preconditioning in parallel. Here, Petsc provides an > interface to BlockSolve95 but requires the matrix format MPIBAIJ. So far > MPIAIJ is standard in libmesh. Do you think I can just change the matrix > format or does that cause any problems (with parmetis or whatever)? I've often wondered this myself...unfortunately I don't know enough about the different Petsc matrix types to say for sure. If you do get something working, for example a user-selectable PETSc matrix type, we would definitely be interested in getting it in the library. > Or do you have any idea how to work arround that? There are a couple other parallel ILU implementations in hypre, pilut (unsupported but still works) and euclid. I'm not sure what your research goals are, but I and some others have typically gotten better performance from block jacobi ... it's not as good a preconditioner but it's enough faster than the parallel ILU implementations to make it attractive on a wall-clock time basis. -- John |
From: John P. <jwp...@gm...> - 2008-06-17 13:49:05
|
On Tue, Jun 17, 2008 at 8:35 AM, Jan Biermann <bie...@tu...> wrote: > > by the way, how does the commit of code work? I did implement some stuff > regarding the infinite elements (some other shapes) and SZABAB elements in > 3D up to order four (and the respective IFE with a SZABAB basis). I'd like > to provide that to the community. It can work in one of two ways: you can send us a patch (I think the output of svn diff works sufficiently well for this) or you can become a LibMesh developer. I guess usually we prefer to receive a few patches before giving someone svn commit access...did you work with Steffen Petersen previously? -- John |
From: Jed B. <je...@59...> - 2008-06-20 13:31:37
|
On Tue, Jun 17, 2008 at 15:22, John Peterson <jwp...@gm...> wrote: > On Tue, Jun 17, 2008 at 8:09 AM, Jan Biermann <bie...@tu...> wrote: >> Hi, >> I would like to use ILU preconditioning in parallel. Here, Petsc provides an >> interface to BlockSolve95 but requires the matrix format MPIBAIJ. So far >> MPIAIJ is standard in libmesh. Do you think I can just change the matrix >> format or does that cause any problems (with parmetis or whatever)? > > I've often wondered this myself...unfortunately I don't know enough > about the different Petsc matrix types to say for sure. If you do get > something working, for example a user-selectable PETSc matrix type, we > would definitely be interested in getting it in the library. I'm not sure what you mean and I don't have source code in front of me, but what is wrong with this? MatCreate() MatSetType() // default MatSetFromOptions() MatMPIAIJSetPreallocation() MatMPIBAIJSetPreallocation() MatSeqAIJSetPreallocation() MatSeqBAIJSetPreallocation() // you can call all of these and they will be a no-op if the type does not match. >> Or do you have any idea how to work arround that? > > There are a couple other parallel ILU implementations in hypre, pilut > (unsupported but still works) and euclid. I'm not sure what your > research goals are, but I and some others have typically gotten better > performance from block jacobi ... it's not as good a preconditioner > but it's enough faster than the parallel ILU implementations to make > it attractive on a wall-clock time basis. Or domain decomposition preconditioners (try -pc_type asm and play with -sub_xxx options) which can often be made much stronger than block jacobi with only a modest increase in communication costs. If the conditioning is really bad, iterative substructuring would be worth checking out, but it requires a lot more programming effort. Jed |
From: John P. <jwp...@gm...> - 2008-06-20 13:47:42
|
On Fri, Jun 20, 2008 at 8:31 AM, Jed Brown <je...@59...> wrote: > On Tue, Jun 17, 2008 at 15:22, John Peterson <jwp...@gm...> wrote: >> On Tue, Jun 17, 2008 at 8:09 AM, Jan Biermann <bie...@tu...> wrote: >>> Hi, >>> I would like to use ILU preconditioning in parallel. Here, Petsc provides an >>> interface to BlockSolve95 but requires the matrix format MPIBAIJ. So far >>> MPIAIJ is standard in libmesh. Do you think I can just change the matrix >>> format or does that cause any problems (with parmetis or whatever)? >> >> I've often wondered this myself...unfortunately I don't know enough >> about the different Petsc matrix types to say for sure. If you do get >> something working, for example a user-selectable PETSc matrix type, we >> would definitely be interested in getting it in the library. > > I'm not sure what you mean and I don't have source code in front of > me, but what is wrong with this? > > MatCreate() > MatSetType() // default > MatSetFromOptions() > MatMPIAIJSetPreallocation() > MatMPIBAIJSetPreallocation() > MatSeqAIJSetPreallocation() > MatSeqBAIJSetPreallocation() > // you can call all of these and they will be a no-op if the type does > not match. That's good to know...I didn't mean to say it was difficult to do, just that we don't currently have the code for it. Since you can call all of the routines and it will just drop the ones it's not using, that's one way to go. On the PETSc side I wish it could be cleaner...why have two totally separate function names instead of just letting the arguments' types determine the behavior? -- John |
From: Roy S. <ro...@st...> - 2008-06-20 13:53:41
|
On Fri, 20 Jun 2008, John Peterson wrote: > Since you can call all of the routines and it will just drop the ones > it's not using, that's one way to go. On the PETSc side I wish it > could be cleaner...why have two totally separate function names > instead of just letting the arguments' types determine the behavior? It's been *that* long since you used C without the ++, huh? --- Roy |
From: John P. <jwp...@gm...> - 2008-06-20 13:59:52
|
On Fri, Jun 20, 2008 at 8:53 AM, Roy Stogner <ro...@st...> wrote: > > On Fri, 20 Jun 2008, John Peterson wrote: > >> Since you can call all of the routines and it will just drop the ones >> it's not using, that's one way to go. On the PETSc side I wish it >> could be cleaner...why have two totally separate function names >> instead of just letting the arguments' types determine the behavior? > > It's been *that* long since you used C without the ++, huh? I know you were joking but AFAIK, in C you can still do if tests... void f(int arg) { if (arg==1) // do one behavior, call MPIAIJ... if (arg==2) // do another behavior } -- John |
From: Roy S. <ro...@st...> - 2008-06-20 14:32:05
|
On Fri, 20 Jun 2008, John Peterson wrote: > On Fri, Jun 20, 2008 at 8:53 AM, Roy Stogner <ro...@st...> wrote: >> >> On Fri, 20 Jun 2008, John Peterson wrote: >> >>> Since you can call all of the routines and it will just drop the ones >>> it's not using, that's one way to go. On the PETSc side I wish it >>> could be cleaner...why have two totally separate function names >>> instead of just letting the arguments' types determine the behavior? >> >> It's been *that* long since you used C without the ++, huh? > > I know you were joking but AFAIK, in C you can still do if tests... > > void f(int arg) > { > if (arg==1) > // do one behavior, call MPIAIJ... > > if (arg==2) > // do another behavior > } Yeah, but that only works if you've got an "enum what_type_am_i" member variable to test, and if you hide all non-common struct variables behind a "void *" or something. You still can't have both f(SparseMatrix) and f(BlockSparseMatrix) in C unless SparseMatrix and BlockSparseMatrix are the exact same type in the compiler's eyes. --- Roy |