[petsc-users] CVODE N_Vector PETSc interface gives a memory corruption error
Matthew Knepley
knepley at gmail.com
Thu Nov 19 09:21:57 CST 2020
On Thu, Nov 19, 2020 at 10:05 AM Praharsh Suryadevara <surya031 at umn.edu>
wrote:
> Thanks!
> The main reason is I want to be able to use SNES within CVODE as they
> state in the sundials manual; however, the notes in the documentation
> here
> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSUNDIALS.html
> states that it uses the sundials, internal solver. Is there a way
> around that?
>
You are correct that the TSSUNDIALS uses their internal solver. So
1) you can make a bug report to SUNDIALS to get them to fix the PETSc
interface, or
2) see if you can use an equivalent stepper in TS
Maybe we can do 2) while we wait for 1)?
Thanks,
Matt
> Thanks,
> Praharsh
>
> On Thu, Nov 19, 2020 at 7:36 AM Matthew Knepley <knepley at gmail.com> wrote:
> >
> > On Wed, Nov 18, 2020 at 11:11 PM Praharsh Suryadevara via petsc-users <
> petsc-users at mcs.anl.gov> wrote:
> >>
> >> Hi All,
> >> I asked this on StackOverflow but I realized it's better off asked here,
> >>
> >> I'm trying to use the CVODE_PETSc interface, and I've been getting
> >> memory corruption errors I couldn't understand, so I tried to make a
> >> minimal reproducible example for one below. Running this,
> >
> >
> > There is a bug in CVODE's PETSc interface:
> >
> > ==16192== Invalid write of size 8
> > ==16192== at 0x4E4553C: N_VNewEmpty_Petsc (in
> /home/praharsh/.local/lib/libsundials_nvecpetsc.so.5.5.0)
> > ==16192== by 0x4E45630: N_VMake_Petsc (in
> /home/praharsh/.local/lib/libsundials_nvecpetsc.so.5.5.0)
> > ==16192== by 0x108AF8: main (in
> /home/praharsh/.local/examples/cvode/petsc/cv_petsc_ex7)
> > ==16192== Address 0xfaf8708 is 0 bytes after a block of size 392 alloc'd
> > ==16192== at 0x4C2FB0F: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> > ==16192== by 0x4044922: ??? (in
> /var/empty/local/lib/libsundials_cvode.so.5.3.0)
> > ==16192== by 0x84000001: ???
> > ==16192== by 0x4E4532E: N_VNewEmpty_Petsc (in
> /home/praharsh/.local/lib/libsundials_nvecpetsc.so.5.5.0)
> > ==16192== by 0x4E45630: N_VMake_Petsc (in
> /home/praharsh/.local/lib/libsundials_nvecpetsc.so.5.5.0)
> > ==16192== by 0x108AF8: main (in
> /home/praharsh/.local/examples/cvode/petsc/cv_petsc_ex7)
> >
> > An alternative is to use CVODE through PETSc, meaning you would
> configure using --download-sundials, and
> > then use the CVODE solvers from Sundials.
> >
> > Thanks,
> >
> > Matt
> >
> >>
> >> int main(int argc,char **argv)
> >>
> >> {
> >> N_Vector nvecx;
> >> PetscErrorCode ierr;
> >> Vec x;
> >> int nr_dof = 3;
> >> PetscInitializeNoArguments();
> >> VecCreateSeq(PETSC_COMM_SELF, nr_dof, &x);
> >> VecZeroEntries(x);
> >> VecAssemblyBegin(x);
> >> VecAssemblyEnd(x);
> >> nvecx = N_VMake_Petsc(x);
> >> if (check_retval((void *)nvecx, "N_VMake_Petsc", 0)) return 1;
> >> N_VDestroy(nvecx);
> >> ierr = VecDestroy(&x);CHKERRQ(ierr);
> >> printf("Corruption is happening below\n");
> >> ierr = PetscFinalize();
> >> printf("PETSC FINALIZE\n");
> >> return ierr;
> >> }
> >>
> >> gives me
> >>
> >> Corruption is happening below
> >> double free or corruption (out)
> >> [1] 14133 abort (core dumped) ./cv_petsc_ex7
> >>
> >> I've also attached the output of valgrind --leak-check=full
> >> ./my_program_executable &> valgrind_output.log
> >> I'm not particularly sure why PetscFinalize is causing memory
> >> corruption here. I'm using Sundials 5.5.0 and Petsc 3.14.0. I don't
> >> really understand CVODE or PETSc internals or manual memory management
> >> well since I'm new to all of them. Any help pinpointing the issue
> >> would be appreciated.
> >>
> >> Thank you!
> >> Praharsh
> >
> >
> >
> > --
> > 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
> >
> > https://www.cse.buffalo.edu/~knepley/
>
--
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
https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20201119/cef711ea/attachment.html>
More information about the petsc-users
mailing list