From: Kyunghoon L. <aer...@gm...> - 2011-10-27 23:23:58
|
Hi all, I compiled petsc with complex variable support using the following options: ./configure --prefix=/Users/aeronova/ Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1 --download-blacs=1 --download-parmetis=1 --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx Then, rebuild slepc & libmesh (svn version). As I test libmesh with examples, I got an error for ex17 (plz see the below). I'd appreciate if someone could help me with this problem. (ex7, complex variable example, seemed ok, though there were a couple of warnings such as WARNING! There are options you set that were not used!, WARNING! could be spelling mistake, etc!, Option left: name:-f value: .5) [0]PETSC ERROR: --------------------- Error Message ------------------------------------ [0]PETSC ERROR: IPNorm: The inner product is not well defined! [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 8, Thu Mar 17 13:37:48 CDT 2011 [0]PETSC ERROR: See docs/changes/index.html for recent updates. [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [0]PETSC ERROR: See docs/index.html for manual pages. [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: ./ex17-dbg on a darwin10. named spike.local by aeronova Fri Oct 28 05:13:59 2011 [0]PETSC ERROR: Libraries linked from /Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8/lib [0]PETSC ERROR: Configure run at Fri Oct 28 04:12:19 2011 [0]PETSC ERROR: Configure options --prefix=/Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8 --download-mpich=1 --download-blacs=1 --download-parmetis=1 --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: IPNorm() line 70 in src/ip/ipdot.c [0]PETSC ERROR: IPOrthogonalize() line 338 in src/ip/iporthog.c [0]PETSC ERROR: EPSGetStartVector() line 1487 in src/eps/interface/solve.c [0]PETSC ERROR: EPSSolve_ARNOLDI() line 387 in src/eps/impls/krylov/arnoldi/arnoldi.c [0]PETSC ERROR: EPSSolve() line 146 in src/eps/interface/solve.c [0]PETSC ERROR: User provided function() line 488 in "unknowndirectory/"src/solvers/slepc_eigen_solver.C application called MPI_Abort(comm=0x84000000, 1) - process 0[unset]: aborting job: application called MPI_Abort(comm=0x84000000, 1) - process 0 make[2]: *** [run] Error 1 make[1]: *** [run] Error 1 make: *** [run_examples] Error 2 |
From: Roy S. <roy...@ic...> - 2011-10-27 23:30:18
|
What options did you use to configure libMesh? I'll see if I can reproduce this. We currently have --enable-complex BuildBot tests and --enable-slepc tests but I don't think we're testing the combination of the two... --- Roy On Fri, 28 Oct 2011, Kyunghoon Lee wrote: > Hi all, > > I compiled petsc with complex variable support using the following options: > > ./configure --prefix=/Users/aeronova/ > Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1 > --download-blacs=1 --download-parmetis=1 --download-scalapack=1 > --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx > > Then, rebuild slepc & libmesh (svn version). As I test libmesh with > examples, I got an error for ex17 (plz see the below). I'd appreciate if > someone could help me with this problem. (ex7, complex variable example, > seemed ok, though there were a couple of warnings such as WARNING! There are > options you set that were not used!, WARNING! could be spelling mistake, > etc!, Option left: name:-f value: .5) > > > [0]PETSC ERROR: --------------------- Error Message > ------------------------------------ > [0]PETSC ERROR: IPNorm: The inner product is not well defined! > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 8, Thu Mar 17 13:37:48 > CDT 2011 > [0]PETSC ERROR: See docs/changes/index.html for recent updates. > [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [0]PETSC ERROR: See docs/index.html for manual pages. > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: ./ex17-dbg on a darwin10. named spike.local by aeronova Fri > Oct 28 05:13:59 2011 > [0]PETSC ERROR: Libraries linked from > /Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8/lib > [0]PETSC ERROR: Configure run at Fri Oct 28 04:12:19 2011 > [0]PETSC ERROR: Configure options > --prefix=/Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8 > --download-mpich=1 --download-blacs=1 --download-parmetis=1 > --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex > --with-clanguage=cxx > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: IPNorm() line 70 in src/ip/ipdot.c > [0]PETSC ERROR: IPOrthogonalize() line 338 in src/ip/iporthog.c > [0]PETSC ERROR: EPSGetStartVector() line 1487 in src/eps/interface/solve.c > [0]PETSC ERROR: EPSSolve_ARNOLDI() line 387 in > src/eps/impls/krylov/arnoldi/arnoldi.c > [0]PETSC ERROR: EPSSolve() line 146 in src/eps/interface/solve.c > [0]PETSC ERROR: User provided function() line 488 in > "unknowndirectory/"src/solvers/slepc_eigen_solver.C > application called MPI_Abort(comm=0x84000000, 1) - process 0[unset]: > aborting job: > application called MPI_Abort(comm=0x84000000, 1) - process 0 > make[2]: *** [run] Error 1 > make[1]: *** [run] Error 1 > make: *** [run_examples] Error 2 > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > |
From: Roy S. <roy...@ic...> - 2011-11-01 19:28:28
|
We're testing SLEPc + complex now, and seeing the same IPNorm error. The problem seems to be some issue with the default iterative solvers we tell SLEPc to use; it looks like for some reason they're getting a "norm" of their initial random starting vector that isn't a non-negative real number. I'm not sure how this would happen, though a Google search suggests that we're not the first people to run into this IPNorm error when doing a generalized eigenproblem. Running with LIBMESH_OPTIONS="-eps_type lapack" comes up with results; I presume that's switching to a direct solver. This probably isn't SLEPc's fault, but if you're doing eigen problems with complex-valued PDEs then you might want to ask them about this issue anyway; I don't know enough about our SLEPc interface or about the various methods they have available to advise you on which to use. For now I'm going to put "-eps_type lapack" in our ex17 Makefile just to get it passing tests; however if you learn more about what we might be doing wrong that's confusing their Arnoldi solver then I'd appreciate hearing about it. Thanks, --- Roy On Thu, 27 Oct 2011, Roy Stogner wrote: > What options did you use to configure libMesh? > > I'll see if I can reproduce this. We currently have --enable-complex > BuildBot tests and --enable-slepc tests but I don't think we're > testing the combination of the two... > --- > Roy > > On Fri, 28 Oct 2011, Kyunghoon Lee wrote: > >> Hi all, >> >> I compiled petsc with complex variable support using the following options: >> >> ./configure --prefix=/Users/aeronova/ >> Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1 >> --download-blacs=1 --download-parmetis=1 --download-scalapack=1 >> --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx >> >> Then, rebuild slepc & libmesh (svn version). As I test libmesh with >> examples, I got an error for ex17 (plz see the below). I'd appreciate if >> someone could help me with this problem. (ex7, complex variable example, >> seemed ok, though there were a couple of warnings such as WARNING! There >> are >> options you set that were not used!, WARNING! could be spelling mistake, >> etc!, Option left: name:-f value: .5) >> >> >> [0]PETSC ERROR: --------------------- Error Message >> ------------------------------------ >> [0]PETSC ERROR: IPNorm: The inner product is not well defined! >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 8, Thu Mar 17 13:37:48 >> CDT 2011 >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. >> [0]PETSC ERROR: See docs/index.html for manual pages. >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: ./ex17-dbg on a darwin10. named spike.local by aeronova Fri >> Oct 28 05:13:59 2011 >> [0]PETSC ERROR: Libraries linked from >> /Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8/lib >> [0]PETSC ERROR: Configure run at Fri Oct 28 04:12:19 2011 >> [0]PETSC ERROR: Configure options >> --prefix=/Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8 >> --download-mpich=1 --download-blacs=1 --download-parmetis=1 >> --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex >> --with-clanguage=cxx >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: IPNorm() line 70 in src/ip/ipdot.c >> [0]PETSC ERROR: IPOrthogonalize() line 338 in src/ip/iporthog.c >> [0]PETSC ERROR: EPSGetStartVector() line 1487 in src/eps/interface/solve.c >> [0]PETSC ERROR: EPSSolve_ARNOLDI() line 387 in >> src/eps/impls/krylov/arnoldi/arnoldi.c >> [0]PETSC ERROR: EPSSolve() line 146 in src/eps/interface/solve.c >> [0]PETSC ERROR: User provided function() line 488 in >> "unknowndirectory/"src/solvers/slepc_eigen_solver.C >> application called MPI_Abort(comm=0x84000000, 1) - process 0[unset]: >> aborting job: >> application called MPI_Abort(comm=0x84000000, 1) - process 0 >> make[2]: *** [run] Error 1 >> make[1]: *** [run] Error 1 >> make: *** [run_examples] Error 2 >> >> ------------------------------------------------------------------------------ >> The demand for IT networking professionals continues to grow, and the >> demand for specialized networking skills is growing even more rapidly. >> Take a complimentary Learning@Cisco Self-Assessment and learn >> about Cisco certifications, training, and career opportunities. >> http://p.sf.net/sfu/cisco-dev2dev >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> > |
From: David K. <dkn...@se...> - 2011-11-01 19:38:02
|
On 11/01/2011 03:28 PM, Roy Stogner wrote: > We're testing SLEPc + complex now, and seeing the same IPNorm error. > > The problem seems to be some issue with the default iterative solvers > we tell SLEPc to use; it looks like for some reason they're getting a > "norm" of their initial random starting vector that isn't a > non-negative real number. I'm not sure how this would happen, though > a Google search suggests that we're not the first people to run into > this IPNorm error when doing a generalized eigenproblem. Interesting. So it's not a bug per se, good to know. > Running with LIBMESH_OPTIONS="-eps_type lapack" comes up with results; > I presume that's switching to a direct solver. The lapack solver uses the QR algorithm (or something similar) to find all the eigenvalues I believe. Its very robust, but only works for small problems since it treats the matrix as dense. Dave >> What options did you use to configure libMesh? >> >> I'll see if I can reproduce this. We currently have --enable-complex >> BuildBot tests and --enable-slepc tests but I don't think we're >> testing the combination of the two... >> --- >> Roy >> >> On Fri, 28 Oct 2011, Kyunghoon Lee wrote: >> >>> Hi all, >>> >>> I compiled petsc with complex variable support using the following options: >>> >>> ./configure --prefix=/Users/aeronova/ >>> Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1 >>> --download-blacs=1 --download-parmetis=1 --download-scalapack=1 >>> --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx >>> >>> Then, rebuild slepc& libmesh (svn version). As I test libmesh with >>> examples, I got an error for ex17 (plz see the below). I'd appreciate if >>> someone could help me with this problem. (ex7, complex variable example, >>> seemed ok, though there were a couple of warnings such as WARNING! There >>> are >>> options you set that were not used!, WARNING! could be spelling mistake, >>> etc!, Option left: name:-f value: .5) >>> >>> >>> [0]PETSC ERROR: --------------------- Error Message >>> ------------------------------------ >>> [0]PETSC ERROR: IPNorm: The inner product is not well defined! >>> [0]PETSC ERROR: >>> ------------------------------------------------------------------------ >>> [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 8, Thu Mar 17 13:37:48 >>> CDT 2011 >>> [0]PETSC ERROR: See docs/changes/index.html for recent updates. >>> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. >>> [0]PETSC ERROR: See docs/index.html for manual pages. >>> [0]PETSC ERROR: >>> ------------------------------------------------------------------------ >>> [0]PETSC ERROR: ./ex17-dbg on a darwin10. named spike.local by aeronova Fri >>> Oct 28 05:13:59 2011 >>> [0]PETSC ERROR: Libraries linked from >>> /Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8/lib >>> [0]PETSC ERROR: Configure run at Fri Oct 28 04:12:19 2011 >>> [0]PETSC ERROR: Configure options >>> --prefix=/Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8 >>> --download-mpich=1 --download-blacs=1 --download-parmetis=1 >>> --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex >>> --with-clanguage=cxx >>> [0]PETSC ERROR: >>> ------------------------------------------------------------------------ >>> [0]PETSC ERROR: IPNorm() line 70 in src/ip/ipdot.c >>> [0]PETSC ERROR: IPOrthogonalize() line 338 in src/ip/iporthog.c >>> [0]PETSC ERROR: EPSGetStartVector() line 1487 in src/eps/interface/solve.c >>> [0]PETSC ERROR: EPSSolve_ARNOLDI() line 387 in >>> src/eps/impls/krylov/arnoldi/arnoldi.c >>> [0]PETSC ERROR: EPSSolve() line 146 in src/eps/interface/solve.c >>> [0]PETSC ERROR: User provided function() line 488 in >>> "unknowndirectory/"src/solvers/slepc_eigen_solver.C >>> application called MPI_Abort(comm=0x84000000, 1) - process 0[unset]: >>> aborting job: >>> application called MPI_Abort(comm=0x84000000, 1) - process 0 >>> make[2]: *** [run] Error 1 >>> make[1]: *** [run] Error 1 >>> make: *** [run_examples] Error 2 >>> >>> ------------------------------------------------------------------------------ >>> The demand for IT networking professionals continues to grow, and the >>> demand for specialized networking skills is growing even more rapidly. >>> Take a complimentary Learning@Cisco Self-Assessment and learn >>> about Cisco certifications, training, and career opportunities. >>> http://p.sf.net/sfu/cisco-dev2dev >>> _______________________________________________ >>> Libmesh-users mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>> >>> > ------------------------------------------------------------------------------ > RSA® Conference 2012 > Save $700 by Nov 18 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Roy S. <roy...@ic...> - 2011-11-01 19:41:58
|
On Tue, 1 Nov 2011, David Knezevic wrote: > On 11/01/2011 03:28 PM, Roy Stogner wrote: >> The problem seems to be some issue with the default iterative solvers >> we tell SLEPc to use; it looks like for some reason they're getting a >> "norm" of their initial random starting vector that isn't a >> non-negative real number. I'm not sure how this would happen, though >> a Google search suggests that we're not the first people to run into >> this IPNorm error when doing a generalized eigenproblem. > > Interesting. So it's not a bug per se, good to know. It might still point to a bug. Our matrices in ex17 should both be real-valued symmetric, right? The stiffness matrix is not invertible, but I don't see how that would cause a problem in C but not in R. --- Roy |
From: Jed B. <je...@59...> - 2011-11-01 19:48:47
|
Kyunghoon, the error messages say petsc-3.1p8, but the configure line makes it look like you are trying to use petsc-3.2. Which is it? I assume that Roy reproduced with a clean petsc-3.2/slepc-3.2 configuration. Jose, do you know what is causing this error? On Tue, Nov 1, 2011 at 13:28, Roy Stogner <roy...@ic...> wrote: > > We're testing SLEPc + complex now, and seeing the same IPNorm error. > > The problem seems to be some issue with the default iterative solvers > we tell SLEPc to use; it looks like for some reason they're getting a > "norm" of their initial random starting vector that isn't a > non-negative real number. I'm not sure how this would happen, though > a Google search suggests that we're not the first people to run into > this IPNorm error when doing a generalized eigenproblem. > > Running with LIBMESH_OPTIONS="-eps_type lapack" comes up with results; > I presume that's switching to a direct solver. > > This probably isn't SLEPc's fault, but if you're doing eigen problems > with complex-valued PDEs then you might want to ask them about this > issue anyway; I don't know enough about our SLEPc interface or about > the various methods they have available to advise you on which to use. > > For now I'm going to put "-eps_type lapack" in our ex17 Makefile just > to get it passing tests; however if you learn more about what we might > be doing wrong that's confusing their Arnoldi solver then I'd > appreciate hearing about it. > > Thanks, > --- > Roy > > On Thu, 27 Oct 2011, Roy Stogner wrote: > > > What options did you use to configure libMesh? > > > > I'll see if I can reproduce this. We currently have --enable-complex > > BuildBot tests and --enable-slepc tests but I don't think we're > > testing the combination of the two... > > --- > > Roy > > > > On Fri, 28 Oct 2011, Kyunghoon Lee wrote: > > > >> Hi all, > >> > >> I compiled petsc with complex variable support using the following > options: > >> > >> ./configure --prefix=/Users/aeronova/ > >> Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1 > >> --download-blacs=1 --download-parmetis=1 --download-scalapack=1 > >> --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx > >> > >> Then, rebuild slepc & libmesh (svn version). As I test libmesh with > >> examples, I got an error for ex17 (plz see the below). I'd appreciate > if > >> someone could help me with this problem. (ex7, complex variable > example, > >> seemed ok, though there were a couple of warnings such as WARNING! There > >> are > >> options you set that were not used!, WARNING! could be spelling mistake, > >> etc!, Option left: name:-f value: .5) > >> > >> > >> [0]PETSC ERROR: --------------------- Error Message > >> ------------------------------------ > >> [0]PETSC ERROR: IPNorm: The inner product is not well defined! > >> [0]PETSC ERROR: > >> ------------------------------------------------------------------------ > >> [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 8, Thu Mar 17 > 13:37:48 > >> CDT 2011 > >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. > >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > >> [0]PETSC ERROR: See docs/index.html for manual pages. > >> [0]PETSC ERROR: > >> ------------------------------------------------------------------------ > >> [0]PETSC ERROR: ./ex17-dbg on a darwin10. named spike.local by aeronova > Fri > >> Oct 28 05:13:59 2011 > >> [0]PETSC ERROR: Libraries linked from > >> /Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8/lib > >> [0]PETSC ERROR: Configure run at Fri Oct 28 04:12:19 2011 > >> [0]PETSC ERROR: Configure options > >> --prefix=/Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8 > >> --download-mpich=1 --download-blacs=1 --download-parmetis=1 > >> --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex > >> --with-clanguage=cxx > >> [0]PETSC ERROR: > >> ------------------------------------------------------------------------ > >> [0]PETSC ERROR: IPNorm() line 70 in src/ip/ipdot.c > >> [0]PETSC ERROR: IPOrthogonalize() line 338 in src/ip/iporthog.c > >> [0]PETSC ERROR: EPSGetStartVector() line 1487 in > src/eps/interface/solve.c > >> [0]PETSC ERROR: EPSSolve_ARNOLDI() line 387 in > >> src/eps/impls/krylov/arnoldi/arnoldi.c > >> [0]PETSC ERROR: EPSSolve() line 146 in src/eps/interface/solve.c > >> [0]PETSC ERROR: User provided function() line 488 in > >> "unknowndirectory/"src/solvers/slepc_eigen_solver.C > >> application called MPI_Abort(comm=0x84000000, 1) - process 0[unset]: > >> aborting job: > >> application called MPI_Abort(comm=0x84000000, 1) - process 0 > >> make[2]: *** [run] Error 1 > >> make[1]: *** [run] Error 1 > >> make: *** [run_examples] Error 2 > >> > >> > ------------------------------------------------------------------------------ > >> The demand for IT networking professionals continues to grow, and the > >> demand for specialized networking skills is growing even more rapidly. > >> Take a complimentary Learning@Cisco Self-Assessment and learn > >> about Cisco certifications, training, and career opportunities. > >> http://p.sf.net/sfu/cisco-dev2dev > >> _______________________________________________ > >> Libmesh-users mailing list > >> Lib...@li... > >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > >> > >> > > > > > ------------------------------------------------------------------------------ > RSA® Conference 2012 > Save $700 by Nov 18 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
From: Roy S. <roy...@ic...> - 2011-11-01 19:55:37
|
On Tue, 1 Nov 2011, Jed Brown wrote: > Kyunghoon, the error messages say petsc-3.1p8, but the configure line makes it look like you are trying to use petsc-3.2. Which > is it? I assume that Roy reproduced with a clean petsc-3.2/slepc-3.2 configuration. Actually, no - I just built against the newest versions we had lying around: petsc-3.1-p5 and slepc-3.1-p4. I'd be happy to upgrade and test the latest if it'd be helpful with any bug hunting, though. --- Roy |
From: Kyunghoon L. <aer...@gm...> - 2011-11-02 00:28:55
|
Jed, I have tested two different sets: petsc-3.1/slpec-3.1 and petsc-3.2/slepc-3.2 --- both cases ex17 failed generating the same error log. On Wed, Nov 2, 2011 at 3:48 AM, Jed Brown <je...@59...> wrote: > Kyunghoon, the error messages say petsc-3.1p8, but the configure line > makes it look like you are trying to use petsc-3.2. Which is it? I assume > that Roy reproduced with a clean petsc-3.2/slepc-3.2 configuration. > > Jose, do you know what is causing this error? > > On Tue, Nov 1, 2011 at 13:28, Roy Stogner <roy...@ic...>wrote: > >> >> We're testing SLEPc + complex now, and seeing the same IPNorm error. >> >> The problem seems to be some issue with the default iterative solvers >> we tell SLEPc to use; it looks like for some reason they're getting a >> "norm" of their initial random starting vector that isn't a >> non-negative real number. I'm not sure how this would happen, though >> a Google search suggests that we're not the first people to run into >> this IPNorm error when doing a generalized eigenproblem. >> >> Running with LIBMESH_OPTIONS="-eps_type lapack" comes up with results; >> I presume that's switching to a direct solver. >> >> This probably isn't SLEPc's fault, but if you're doing eigen problems >> with complex-valued PDEs then you might want to ask them about this >> issue anyway; I don't know enough about our SLEPc interface or about >> the various methods they have available to advise you on which to use. >> >> For now I'm going to put "-eps_type lapack" in our ex17 Makefile just >> to get it passing tests; however if you learn more about what we might >> be doing wrong that's confusing their Arnoldi solver then I'd >> appreciate hearing about it. >> >> Thanks, >> --- >> Roy >> >> On Thu, 27 Oct 2011, Roy Stogner wrote: >> >> > What options did you use to configure libMesh? >> > >> > I'll see if I can reproduce this. We currently have --enable-complex >> > BuildBot tests and --enable-slepc tests but I don't think we're >> > testing the combination of the two... >> > --- >> > Roy >> > >> > On Fri, 28 Oct 2011, Kyunghoon Lee wrote: >> > >> >> Hi all, >> >> >> >> I compiled petsc with complex variable support using the following >> options: >> >> >> >> ./configure --prefix=/Users/aeronova/ >> >> Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1 >> >> --download-blacs=1 --download-parmetis=1 --download-scalapack=1 >> >> --download-mumps=1 --with-scalar-type=complex --with-clanguage=cxx >> >> >> >> Then, rebuild slepc & libmesh (svn version). As I test libmesh with >> >> examples, I got an error for ex17 (plz see the below). I'd appreciate >> if >> >> someone could help me with this problem. (ex7, complex variable >> example, >> >> seemed ok, though there were a couple of warnings such as WARNING! >> There >> >> are >> >> options you set that were not used!, WARNING! could be spelling >> mistake, >> >> etc!, Option left: name:-f value: .5) >> >> >> >> >> >> [0]PETSC ERROR: --------------------- Error Message >> >> ------------------------------------ >> >> [0]PETSC ERROR: IPNorm: The inner product is not well defined! >> >> [0]PETSC ERROR: >> >> >> ------------------------------------------------------------------------ >> >> [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 8, Thu Mar 17 >> 13:37:48 >> >> CDT 2011 >> >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. >> >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. >> >> [0]PETSC ERROR: See docs/index.html for manual pages. >> >> [0]PETSC ERROR: >> >> >> ------------------------------------------------------------------------ >> >> [0]PETSC ERROR: ./ex17-dbg on a darwin10. named spike.local by >> aeronova Fri >> >> Oct 28 05:13:59 2011 >> >> [0]PETSC ERROR: Libraries linked from >> >> /Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8/lib >> >> [0]PETSC ERROR: Configure run at Fri Oct 28 04:12:19 2011 >> >> [0]PETSC ERROR: Configure options >> >> --prefix=/Users/aeronova/Development/local/lib64/petsc/petsc-3.1-p8 >> >> --download-mpich=1 --download-blacs=1 --download-parmetis=1 >> >> --download-scalapack=1 --download-mumps=1 --with-scalar-type=complex >> >> --with-clanguage=cxx >> >> [0]PETSC ERROR: >> >> >> ------------------------------------------------------------------------ >> >> [0]PETSC ERROR: IPNorm() line 70 in src/ip/ipdot.c >> >> [0]PETSC ERROR: IPOrthogonalize() line 338 in src/ip/iporthog.c >> >> [0]PETSC ERROR: EPSGetStartVector() line 1487 in >> src/eps/interface/solve.c >> >> [0]PETSC ERROR: EPSSolve_ARNOLDI() line 387 in >> >> src/eps/impls/krylov/arnoldi/arnoldi.c >> >> [0]PETSC ERROR: EPSSolve() line 146 in src/eps/interface/solve.c >> >> [0]PETSC ERROR: User provided function() line 488 in >> >> "unknowndirectory/"src/solvers/slepc_eigen_solver.C >> >> application called MPI_Abort(comm=0x84000000, 1) - process 0[unset]: >> >> aborting job: >> >> application called MPI_Abort(comm=0x84000000, 1) - process 0 >> >> make[2]: *** [run] Error 1 >> >> make[1]: *** [run] Error 1 >> >> make: *** [run_examples] Error 2 >> >> >> >> >> ------------------------------------------------------------------------------ >> >> The demand for IT networking professionals continues to grow, and the >> >> demand for specialized networking skills is growing even more rapidly. >> >> Take a complimentary Learning@Cisco Self-Assessment and learn >> >> about Cisco certifications, training, and career opportunities. >> >> http://p.sf.net/sfu/cisco-dev2dev >> >> _______________________________________________ >> >> Libmesh-users mailing list >> >> Lib...@li... >> >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> >> >> >> > >> >> >> ------------------------------------------------------------------------------ >> RSA® Conference 2012 >> Save $700 by Nov 18 >> Register now! >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> > > |
From: David K. <dkn...@se...> - 2011-11-01 19:51:35
|
On 11/01/2011 03:41 PM, Roy Stogner wrote: > > On Tue, 1 Nov 2011, David Knezevic wrote: > >> On 11/01/2011 03:28 PM, Roy Stogner wrote: > >>> The problem seems to be some issue with the default iterative solvers >>> we tell SLEPc to use; it looks like for some reason they're getting a >>> "norm" of their initial random starting vector that isn't a >>> non-negative real number. I'm not sure how this would happen, though >>> a Google search suggests that we're not the first people to run into >>> this IPNorm error when doing a generalized eigenproblem. >> >> Interesting. So it's not a bug per se, good to know. > > It might still point to a bug. Our matrices in ex17 should both be > real-valued symmetric, right? The stiffness matrix is not invertible, > but I don't see how that would cause a problem in C but not in R. True. One thought is that I've always thought that ex17 was a bit strange since we're looking for sup_v a(v,v) / m(v,v) which is unbounded as h --> 0. Perhaps things are more fragile because of this high-frequency mode? Does ex17 work with complex numbers if you uncomment the line: eigen_system.eigen_solver->set_position_of_spectrum(SMALLEST_MAGNITUDE); |
From: Roy S. <roy...@ic...> - 2011-11-01 20:10:23
|
On Tue, 1 Nov 2011, David Knezevic wrote: > One thought is that I've always thought that ex17 was a bit strange since > we're looking for > > sup_v a(v,v) / m(v,v) > > which is unbounded as h --> 0. Perhaps things are more fragile because of > this high-frequency mode? Does ex17 work with complex numbers if you > uncomment the line: > > eigen_system.eigen_solver->set_position_of_spectrum(SMALLEST_MAGNITUDE); Still fails for me. As I'd expect it to, I think. Even with an ill-defined infinite-dimensional problem, we ought to be getting something vaguely resembling the highest frequency mode capturable by the mesh for the discretized problem. --- Roy |
From: David K. <dkn...@se...> - 2011-11-01 20:16:19
|
On 11/01/2011 04:10 PM, Roy Stogner wrote: > > On Tue, 1 Nov 2011, David Knezevic wrote: > >> One thought is that I've always thought that ex17 was a bit strange >> since we're looking for >> >> sup_v a(v,v) / m(v,v) >> >> which is unbounded as h --> 0. Perhaps things are more fragile >> because of this high-frequency mode? Does ex17 work with complex >> numbers if you uncomment the line: >> >> eigen_system.eigen_solver->set_position_of_spectrum(SMALLEST_MAGNITUDE); > > Still fails for me. > > As I'd expect it to, I think. Even with an ill-defined > infinite-dimensional problem, we ought to be getting something vaguely > resembling the highest frequency mode capturable by the mesh for the > discretized problem. OK, no big deal. Yeah, we do get an approximation to the highest frequency mode on the mesh in the real case. I just thought that changing to the lowest mode would make the problem "easier" and let us see if slepc is more fragile in the complex case... |
From: Jed B. <je...@59...> - 2011-11-01 20:13:15
|
On Tue, Nov 1, 2011 at 14:06, Jose E. Roman <jr...@ds...> wrote: > > El 01/11/2011, a las 20:55, Roy Stogner escribió: > > > > > On Tue, 1 Nov 2011, Jed Brown wrote: > > > >> Kyunghoon, the error messages say petsc-3.1p8, but the configure line > makes it look like you are trying to use petsc-3.2. Which > >> is it? I assume that Roy reproduced with a clean petsc-3.2/slepc-3.2 > configuration. > > > > Actually, no - I just built against the newest versions we had lying > > around: petsc-3.1-p5 and slepc-3.1-p4. I'd be happy to upgrade and > > test the latest if it'd be helpful with any bug hunting, though. > > --- > > Roy > > > The error "IPNorm: The inner product is not well defined!" is usually due > to the fact that the B matrix of the eigenproblem is not positive (semi) > definite. Are you sure your eigenproblem is definite? In that case, I would > be interested in trying these matrices to track down the problem. > It is supposed to be a finite element generalized eigenproblem where A is the Laplacian and B is a mass matrix (using Q_1 quadrilateral elements on [-1,1]^2). |
From: John P. <jwp...@gm...> - 2011-11-01 20:20:25
|
On Tue, Nov 1, 2011 at 2:13 PM, Jed Brown <je...@59...> wrote: > On Tue, Nov 1, 2011 at 14:06, Jose E. Roman <jr...@ds...> wrote: > >> >> El 01/11/2011, a las 20:55, Roy Stogner escribió: >> >> > >> > On Tue, 1 Nov 2011, Jed Brown wrote: >> > >> >> Kyunghoon, the error messages say petsc-3.1p8, but the configure line >> makes it look like you are trying to use petsc-3.2. Which >> >> is it? I assume that Roy reproduced with a clean petsc-3.2/slepc-3.2 >> configuration. >> > >> > Actually, no - I just built against the newest versions we had lying >> > around: petsc-3.1-p5 and slepc-3.1-p4. I'd be happy to upgrade and >> > test the latest if it'd be helpful with any bug hunting, though. >> > --- >> > Roy >> >> >> The error "IPNorm: The inner product is not well defined!" is usually due >> to the fact that the B matrix of the eigenproblem is not positive (semi) >> definite. Are you sure your eigenproblem is definite? In that case, I would >> be interested in trying these matrices to track down the problem. >> > > It is supposed to be a finite element generalized eigenproblem where A is > the Laplacian and B is a mass matrix (using Q_1 quadrilateral elements on > [-1,1]^2). I actually don't see where we define boundary conditions on either of the matrices in ex17. So does that mean the problem is indefinite? -- John |
From: Roy S. <roy...@ic...> - 2011-11-01 20:31:29
|
On Tue, 1 Nov 2011, Jed Brown wrote: > The error "IPNorm: The inner product is not well defined!" is > usually due to the fact that the B matrix of the eigenproblem is not > positive (semi) definite. Are you sure your eigenproblem is > definite? It's definitely *supposed* to be; this is just the ex17 code that builds a laplacian stiffness and L2 mass matrix, as you said. I can even switch from Q_1 quads to P_1 line segments, and as long as I use at least 3 of them (4 nodes) I still get that IPNorm error. Although, tweaking the mesh does seem to change the stack trace; the IPNorm starts coming from different calls to IPOrthogonalize, then from EPSComputeVectors_Hermitian, as I shrink things. > In that case, I would be interested in trying these > matrices to track down the problem. matrix_A = [Real part: 1.5 -1.5 0 0 -1.5 3 -1.5 0 0 -1.5 3 -1.5 0 0 -1.5 1.5 Imaginary part: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]; matrix_B = [Real part: 0.222222 0.111111 0 0 0.111111 0.444444 0.111111 0 0 0.111111 0.444444 0.111111 0 0 0.111111 0.222222 Imaginary part: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]; I forgot to set_precision() on that, but you get the idea. matrix_B is SPD. matrix_A isn't, but that just ought to mean that one of our eigenvalues is 0, right? --- Roy |
From: David K. <dkn...@se...> - 2011-11-01 20:41:37
|
On 11/01/2011 04:31 PM, Roy Stogner wrote: > On Tue, 1 Nov 2011, Jed Brown wrote: > >> The error "IPNorm: The inner product is not well defined!" is >> usually due to the fact that the B matrix of the eigenproblem is not >> positive (semi) definite. Are you sure your eigenproblem is >> definite? > It's definitely *supposed* to be; this is just the ex17 code that > builds a laplacian stiffness and L2 mass matrix, as you said. I can > even switch from Q_1 quads to P_1 line segments, and as long as I use > at least 3 of them (4 nodes) I still get that IPNorm error. Although, > tweaking the mesh does seem to change the stack trace; the IPNorm > starts coming from different calls to IPOrthogonalize, then from > EPSComputeVectors_Hermitian, as I shrink things. > >> In that case, I would be interested in trying these >> matrices to track down the problem. > matrix_A = [Real part: > 1.5 -1.5 0 0 > -1.5 3 -1.5 0 > 0 -1.5 3 -1.5 > 0 0 -1.5 1.5 > > Imaginary part: > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > ]; > > matrix_B = [Real part: > 0.222222 0.111111 0 0 > 0.111111 0.444444 0.111111 0 > 0 0.111111 0.444444 0.111111 > 0 0 0.111111 0.222222 > > Imaginary part: > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > ]; > > I forgot to set_precision() on that, but you get the idea. > > matrix_B is SPD. matrix_A isn't, but that just ought to mean that one > of our eigenvalues is 0, right? Yeah, I agree. Plus, it works with -eps_type lapack, so the problem can't be ill-posed... |
From: David K. <dkn...@se...> - 2011-11-01 21:27:47
|
On 11/01/2011 04:31 PM, Roy Stogner wrote: > On Tue, 1 Nov 2011, Jed Brown wrote: > >> The error "IPNorm: The inner product is not well defined!" is >> usually due to the fact that the B matrix of the eigenproblem is not >> positive (semi) definite. Are you sure your eigenproblem is >> definite? > It's definitely *supposed* to be; this is just the ex17 code that > builds a laplacian stiffness and L2 mass matrix, as you said. I can > even switch from Q_1 quads to P_1 line segments, and as long as I use > at least 3 of them (4 nodes) I still get that IPNorm error. Although, > tweaking the mesh does seem to change the stack trace; the IPNorm > starts coming from different calls to IPOrthogonalize, then from > EPSComputeVectors_Hermitian, as I shrink things. > >> In that case, I would be interested in trying these >> matrices to track down the problem. > matrix_A = [Real part: > 1.5 -1.5 0 0 > -1.5 3 -1.5 0 > 0 -1.5 3 -1.5 > 0 0 -1.5 1.5 > > Imaginary part: > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > ]; > > matrix_B = [Real part: > 0.222222 0.111111 0 0 > 0.111111 0.444444 0.111111 0 > 0 0.111111 0.444444 0.111111 > 0 0 0.111111 0.222222 > > Imaginary part: > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > ]; > > I forgot to set_precision() on that, but you get the idea. > > matrix_B is SPD. matrix_A isn't, but that just ought to mean that one > of our eigenvalues is 0, right? Roy, I've attached a version of ex17 with dirichlet boundary conditions, if you're interested in testing that out in complex mode. (Note: it uses CondensedEigenSystem, which I use in rbOOmit in order to compute eigenvalues without introducing spurious behavior due to the presence of Dirichlet dofs) David |
From: Roy S. <roy...@ic...> - 2011-11-01 21:37:16
|
On Tue, 1 Nov 2011, David Knezevic wrote: > Roy, I've attached a version of ex17 with dirichlet boundary conditions, if > you're interested in testing that out in complex mode. (Note: it uses > CondensedEigenSystem, which I use in rbOOmit in order to compute eigenvalues > without introducing spurious behavior due to the presence of Dirichlet dofs) It was worth a try, anyway. I get the same error, but now it takes 5 EDGE2 elements rather than 3 to trigger it. --- Roy |