May 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Spelling Chebyshev
by Jed Brown 10 May '12

10 May '12

On Thu, May 10, 2012 at 3:19 PM, Hong Zhang <hzhang(a)mcs.anl.gov> wrote: > Jed : > >> This rename needs to be documented in dev.html. >> >> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/9ffb4f0fe85d > > > Pushed. > > >> >> Should we register both spellings (they are both used, though Chebyshev >> is more common). >> > > I do not see Chebychev is being used. Good search ' Chebychev' fails as > well. > 484,000 results on google. http://en.wikipedia.org/wiki/Pafnuty_Chebyshev

1 0

Re: [petsc-dev] Spelling Chebyshev
by Hong Zhang 10 May '12

10 May '12

Jed : > This rename needs to be documented in dev.html. > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/9ffb4f0fe85d Pushed. > > Should we register both spellings (they are both used, though Chebyshev is > more common). > I do not see Chebychev is being used. Good search ' Chebychev' fails as well. Hong

1 0

Re: [petsc-dev] discrepancy with bcgs, mpi, cusp, and no preconditioning
by Matthew Knepley 10 May '12

10 May '12

On Thu, May 10, 2012 at 3:45 PM, Chetan Jhurani <chetan.jhurani(a)gmail.com>wrote: > Hi wizards of "->ops->" indirections, > > I'm trying to use bcgs without preconditioning, for now, and > the iterations using "-vec_type cusp -mat_type mpiaijcusp" don't > match serial or non-GPU options. I've attached the test program > and the 4 outputs (serial/parallel + CPU/GPU). All this is > with petsc-dev downloaded now and real scalars. > > Only the parallel GPU results are different starting from > third residual norm seen in results.txt. The other three match > one another. Am I doing something wrong? > > fbcgs (bcgs with -ksp_bcgs_flexible) works fine with all the > serial/parallel or CPU/GPU options I've tried. > > Let me know if you need the matrix, rhs, and initial guess > binary files that are read in by the test program. > That would be great. This looks like a bug that should be tracked down. MAtt > Thanks, > > Chetan > > -- 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

discrepancy with bcgs, mpi, cusp, and no preconditioning
by Chetan Jhurani 10 May '12

10 May '12

Hi wizards of "->ops->" indirections, I'm trying to use bcgs without preconditioning, for now, and the iterations using "-vec_type cusp -mat_type mpiaijcusp" don't match serial or non-GPU options. I've attached the test program and the 4 outputs (serial/parallel + CPU/GPU). All this is with petsc-dev downloaded now and real scalars. Only the parallel GPU results are different starting from third residual norm seen in results.txt. The other three match one another. Am I doing something wrong? fbcgs (bcgs with -ksp_bcgs_flexible) works fine with all the serial/parallel or CPU/GPU options I've tried. Let me know if you need the matrix, rhs, and initial guess binary files that are read in by the test program. Thanks, Chetan

1 0

Re: [petsc-dev] API changes in MatIS
by Stefano Zampini 10 May '12

10 May '12

> This is to do recursive BDDC or what? > > Yes. When creating the BDDC coarse matrix, now the code has three 3 options A) coarse matrix is a MATIS -> multilevel BDDC B) coarse matrix is SEQAIJ -> one level BDDC with only one proc (or all) solving directly the coarse problem C) coarse matrix is MPIAIJ -> one level BDDC with a parallel direct solve I think that PCREDUNDANT can do the job in both cases of options B if the matrix would be parallel.

1 0

Re: [petsc-dev] API changes in MatIS
by Jed Brown 10 May '12

10 May '12

On Thu, May 10, 2012 at 2:19 PM, Stefano Zampini <stefano.zampini(a)gmail.com>wrote: > For MatIS, I would be fine with creating a new MatIS using the same local >> matrices on a subcommunicator, then MatConvert'ing it to AIJ (that will do >> assembly), and discarding the temporary subcomm MatIS. >> > > So, I need to implement MatConvert_MATIS_AIJ. > > I need such a procedure to create a new MATIS representing the BDDC coarse > matrix, not to assemble a parallel matrix. Note that the converted matrix > should be SEQAIJ for actual implementation of PETSc MATIS. This is to do recursive BDDC or what? MatConvert does not change the linear operator, it just changes the format. I get the impression from this email that you want to make it do more than that. > It seems to me that the best logic should then be > > if(im_active_on_the_next_level) > MatCreateSEQAIJ(PETSC_COMM_SELF,A_MATIS_NEW... > MatConvert(A_MATIS,MATAIJ,MAT_REUSE_MATRIX,&A_MATIS_NEW) > > Mat_Convert_MATIS_AIJ should than detect the only process having already > created the converted matrix. In case you need a parallel AIJ matrix , then > the call should be > > MatConvert(A_MATIS,MATAIJ,MAT_INITIAL_MATRIX,&A_MATIS_NEW) > > and A_MATIS_NEW should than be created by the procedure and take the same > comm of A_MATIS. Is it fine for you? > > -- > Stefano >

1 0

Re: [petsc-dev] API changes in MatIS
by Stefano Zampini 10 May '12

10 May '12

> > For MatIS, I would be fine with creating a new MatIS using the same local > matrices on a subcommunicator, then MatConvert'ing it to AIJ (that will do > assembly), and discarding the temporary subcomm MatIS. > So, I need to implement MatConvert_MATIS_AIJ. I need such a procedure to create a new MATIS representing the BDDC coarse matrix, not to assemble a parallel matrix. Note that the converted matrix should be SEQAIJ for actual implementation of PETSc MATIS. It seems to me that the best logic should then be if(im_active_on_the_next_level) MatCreateSEQAIJ(PETSC_COMM_SELF,A_MATIS_NEW... MatConvert(A_MATIS,MATAIJ,MAT_REUSE_MATRIX,&A_MATIS_NEW) Mat_Convert_MATIS_AIJ should than detect the only process having already created the converted matrix. In case you need a parallel AIJ matrix , then the call should be MatConvert(A_MATIS,MATAIJ,MAT_INITIAL_MATRIX,&A_MATIS_NEW) and A_MATIS_NEW should than be created by the procedure and take the same comm of A_MATIS. Is it fine for you? -- Stefano

1 0

Spelling Chebyshev
by Jed Brown 10 May '12

10 May '12

This rename needs to be documented in dev.html. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/9ffb4f0fe85d Should we register both spellings (they are both used, though Chebyshev is more common).

1 0

Re: [petsc-dev] OpenMP Support
by Dave Nystrom 09 May '12

09 May '12

Hi Gerard, Thanks for the info. Is there any documentation on how to use the petsc OpenMP support? I would be interested in trying it out. Thanks, Dave Gerard Gorman writes: > Hi Dave > > OpenMP support exists for vec and mat (only AIJ so far). There is a big > difference in performance depending on available memory bandwidth and > the compiler OpenMP implementation. In application codes (such as > Fluidity which is our main target code for this work) there are other > significant costs such as matrix assembly. So in general you have to > consider how easy it will be to thread to the other computationally > expensive sections of your code, otherwise the overall speed-up of your > application will be modest. > > Cheers > Gerard > > Dave Nystrom emailed the following on 09/05/12 04:29: > > Is the pthreads support further along than the OpenMP support? I have not > > tried the pthreads support yet. Does either the pthreads support or the > > OpenMP support implement the matvec or do they just do vector type > > operations? > > > > Jed Brown writes: > > > On Tue, May 8, 2012 at 9:23 PM, Dave Nystrom <dnystrom1(a)comcast.net> wrote: > > > > > > > I see that petsc-dev now has some OpenMP support. Would a serial, non-mpi > > > > code that uses petsc-dev be able to gain much performance improvement from > > > > it > > > > now for the case of doing sparse linear solve with cg and jacobi > > > > preconditioning? > > > > > > > > > > The kernels are being transitioned to use the threadcomm, which enables > > > OpenMP and other threading models. > > > > > > We anticipate that pthreads will provide the best performance because > > > operations can be less synchronous than with OpenMP (for which a parallel > > > region implies barrier semantics). But if other parts of an application > > > are using OpenMP, it would be preferable for PETSc to also use OpenMP so > > > that it can share the same thread pool. The same applies to TBB. >

1 0

Re: [petsc-dev] MatWrapML_SHELL
by Barry Smith 09 May '12

09 May '12

On May 9, 2012, at 8:25 PM, John Fettig wrote: > In the function MatWrapML_SHELL, there is a return without creating the shell matrix. I have two questions about it: > > m = mlmat->outvec_leng; > n = mlmat->invec_leng; > if (!m || !n){ > newmat = PETSC_NULL; > PetscFunctionReturn(0); > } > > 1) Should there be an error generated here? > > 2) If not, why does the function return without generating the matrix? This can result in deadlock if some processes return in this clause and some do not. The ones that do not get caught in the MatCreateShell() call. > > Regards, > John > John, Is this a concern based on a code inspection, or do you have a particular case where it crashes? If you have a crashing case could you please send it to us? Thanks Barry

1 0