From: Michael S. <m-s...@us...> - 2005-02-22 12:59:38
|
Hello list, I am having a problem with large systems. When using a square mesh consisting of 10x10 bins (in 2D) my program works fine. When turning to 100x100 bins I get an error message: ** On entry to DGEMV parameter number 6 had an illegal value I am using libmesh 0.4.3 rc2 together with petsc 2.2.0 (the debian testing package) and blas 3 (which comes as a debian dependency for petsc). DGEMV seems to be a blas routine for matrix-vector multiplication. I suspect that petsc is calling this. Can someone help me with this problem? Best greetings, Michael. -- "A mathematician is a device for turning coffee into theorems" Paul Erdös. |
From: John P. <pet...@cf...> - 2005-02-22 14:55:08
|
Michael Schindler writes: > > Hello list, > > I am having a problem with large systems. > When using a square mesh consisting of 10x10 bins (in 2D) > my program works fine. When turning to 100x100 bins > I get an error message: > > > ** On entry to DGEMV parameter number 6 had an illegal value That's definitely an error from the BLAS, but one that I've never seen. We use the Intel MKL BLAS mostly, and have not had many problems. It would probably be difficult for me to reproduce your error message. A 100x100 mesh isn't *that* large, so I don't think that should be the problem, although it is strange that you don't get the same message on the 10x10. If I recall correctly, some other people have had problems with Debian+PETSc before too. If you can, you might want to try building Petsc 2.2.1 from source and linking against the MKL BLAS from the intel web page. In the meantime, what happens if you try to solve the problem with Laspack solvers? What happens if you change the PETSc solver you are using with a -ksp_type flag on the command line? -John |
From: Roy S. <roy...@ic...> - 2005-02-22 16:01:52
|
On Tue, 22 Feb 2005, John Peterson wrote: > Michael Schindler writes: > > > I am having a problem with large systems. > > When using a square mesh consisting of 10x10 bins (in 2D) > > my program works fine. When turning to 100x100 bins > > I get an error message: > > > > ** On entry to DGEMV parameter number 6 had an illegal value > > That's definitely an error from the BLAS, but one that I've never > seen. It's definitely an error from the BLAS, but not necessarily an error in the BLAS-using code. I've seen Laspack segfaults that were merely symptomatic of errors I had made editing DoFMap code; it's likely something similar is occuring here. Michael, I assume you're running in debug (METHOD=dbg) mode? If not, that should be the first thing you try - it's not guaranteed to catch errors as soon as they occur, but it's usually better at it than optimized mode. --- Roy Stogner |
From: Michael S. <m-s...@us...> - 2005-02-23 14:38:39
|
Hello, many thanks for the quick answers. On 22.02.05, Roy Stogner wrote: > On Tue, 22 Feb 2005, John Peterson wrote: > > >> I get an error message: > >> > >> ** On entry to DGEMV parameter number 6 had an illegal value > > > >That's definitely an error from the BLAS, but one that I've never > >seen. > > It's definitely an error from the BLAS, but not necessarily an error > in the BLAS-using code. I've seen Laspack segfaults that were merely > symptomatic of errors I had made editing DoFMap code; it's likely > something similar is occuring here. > > Michael, I assume you're running in debug (METHOD=dbg) mode? If not, > that should be the first thing you try - it's not guaranteed to catch > errors as soon as they occur, but it's usually better at it than > optimized mode. Indeed, I am using (METHOD=dbg) and the appropriate value for (BOPT=g_c++). The error does not occur when using a different solver with -ksp_type It only occured with (-ksp_type gmres), not for solvers tfqmr, bcgs, and bicg. I have also tried the MKL BLAS routines, together with a petsc 2.2.1 linked to the MKL. This also works fine for the case that has failed before. To summarize this, I am not really sure about where the error has come from. I did no changes in the DofMap. Maybe there is something fishy in the dof-constraints system I have written to replace the usual dof constraints. But I doubt this, because it uses only the standard public interface for the matrices, dofmap, ... Best greetings, Michael. -- "A mathematician is a device for turning coffee into theorems" Paul Erdös. |
From: John P. <pet...@cf...> - 2005-02-23 14:47:55
|
Michael Schindler writes: > > The error does not occur when using a different solver with -ksp_type > It only occured with (-ksp_type gmres), not for solvers tfqmr, bcgs, > and bicg. > > I have also tried the MKL BLAS routines, together with a petsc 2.2.1 > linked to the MKL. This also works fine for the case that has failed > before. In that case, I vote for a bad version of GMRES in the PETSc/BLAS distribution for Debian systems. I would not venture to guess why it only shows up for some grids and not others. As an added bonus, you now have the most up-to-date version of PETSc and some fancy BLAS installed :) -John |
From: Roy S. <roy...@ic...> - 2005-02-23 15:03:55
|
On Wed, 23 Feb 2005, Michael Schindler wrote: > I have also tried the MKL BLAS routines, together with a petsc 2.2.1 > linked to the MKL. This also works fine for the case that has failed > before. Ben's apparantly right: it's a limitation with the default Debian BLAS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283731 I hesitate to call it a BLAS bug; based on the results on that page it sounds like a problem in PETSc which other BLAS implementations are just less sensitive to. --- Roy |