I forwarded the first part of this thread to libmesh-devel out of concern that we might have a libMesh issue; 5 seconds later I find out it's a PETSc problem. Carry on, everyone... --- Roy
---------- Forwarded message ---------- Date: Thu, 24 Mar 2011 09:40:03 -0500 From: Barry Smith <[email protected]> To: [email protected], Sebastian Steiger <[email protected]> Cc: Matthew Knepley <[email protected]>, Roy Stogner <[email protected]> Subject: Re: [petsc-maint #67637] Re: [petsc-users] Scalability of AO ? Ah, I see the problem is that SNESLineSearchSetParams() is totally wrongly implemented. It should query the SNES for SNESLineSearchSetParams_LS() and use the function only if it exists. Ancient routine that never got fixed up to the modern style 12 years ago. Thanks for reporting this, we'll update it to the PETSc paradigm in petsc-dev Barry On Mar 24, 2011, at 8:49 AM, Sebastian Steiger wrote: > Matt, > >>> ==14358== Invalid write of size 8 >>> ==14358== at 0xAE305B2: SNESLineSearchSetParams(_p_SNES*, >> double, >>> double, double) (lsparams.c:42) >>> ==14358== by 0x50216E4: >>> NonlinearPoisson::set_numerical_solver_options() >>> (NonlinearPoisson.cpp:998) >> >>> >>> This does not appear to have to do with the last argument. For line >>> lsparams.c:42 of petsc-dev I have >>> >>> if (maxstep >= 0.0) ls->maxstep = maxstep; >>> >> This is fairly simple to look at with gdb. What does the ls struct look >> like? > > > After I recompiled PETSc with -O0 I see the following in gdb: > > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff0b4b5d0 in SNESLineSearchSetParams (snes=0xb0f100, alpha=-2, > maxstep=8.875, minlambda=-2) at lsparams.c:42 > 42 if (maxstep >= 0.0) ls->maxstep = maxstep; > (gdb) print snes > $1 = (SNES) 0xb0f100 > (gdb) print ls > $2 = (SNES_LS *) 0x0 > (gdb) where > #0 0x00007ffff0b4b5d0 in SNESLineSearchSetParams (snes=0xb0f100, > alpha=-2, maxstep=8.875, minlambda=-2) at lsparams.c:42 > #1 0x00007ffff78a96e5 in NonlinearPoisson::set_numerical_solver_options > (this=0xa18890) at NonlinearPoisson.cpp:998 > ... > > So it looks like ls is NULL. When I browse through our code I see that > we're getting the SNES object from libmesh and we're not calling > SNESSetType() explicitly on our side. Might there be a change in default > behavior? > > Maybe you could introduce a small assert that ls!=NULL... > > > >>> 1) My application is used by grad students who do not know >> much about compiling, HPC etc. >>> I think this is orthogonal since we are not talking about users >> building the code, only maintainers that build the code in either case. >> >> Well, our students do build the code because they contribute some small >> parts, but their knowledge is limited to typing 'make'. >> >> Exactly. That should work the same. > > > ... except that we also have SLEPc and libmesh to build which depend on > PETSc. I had to bother Jose Roman and Roy Stogner to get their > dev-versions working with petsc-dev. All in all it's just a painful > process that we'd only like to go through once a year or so. > > Sebastian > > ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
