> On Jan 10, 2021, at 3:25 PM, Sepideh Kavousi <[email protected]> wrote: > > Yes, the entire code is finite difference. > Is it possible that the large Laplacian term makes the equation stiff, such > that the time step is reduced to solve the problem?
Yes, a bit, but no way near to this degree. What are your boundary conditions? Is it possible there is a null space lurking around, unlikely since the direct solver has no issues but if so it could cause difficulties. Barry > Best, > Sepideh > From: Barry Smith <[email protected] <mailto:[email protected]>> > Sent: Thursday, January 7, 2021 1:38 PM > To: Sepideh Kavousi <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Subject: Re: [petsc-users] convergence problem- 3D Cahn Hillard > > > It looks like valgrind is being run on bash, not on your program, so these > leaks are not relevant. by 0x41C482: main (in /usr/bin/bash) > > So the entire code is finite difference based? > > Barry > > >> On Jan 7, 2021, at 12:48 PM, Sepideh Kavousi <[email protected] >> <mailto:[email protected]>> wrote: >> >> I use finite difference and, as an example, the discretization of Pxx is: >> Pxx=((aY[k][j][i+1].p+aY[k][j][i-1].p-2.0*aY[k][j][i].p)/hx2); >> >> I ran the code with valgrind and it seems there is a memory leak problem. >> I am trying to figure out what is causing the memory error. >> Best, >> Sepideh >> >> From: Jed Brown <[email protected] <mailto:[email protected]>> >> Sent: Tuesday, January 5, 2021 10:31 PM >> To: Matthew Knepley <[email protected] <mailto:[email protected]>>; Barry >> Smith <[email protected] <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]> >> <[email protected] <mailto:[email protected]>>; Sepideh Kavousi >> <[email protected] <mailto:[email protected]>> >> Subject: Re: [petsc-users] convergence problem- 3D Cahn Hillard >> >> Matthew Knepley <[email protected] <mailto:[email protected]>> writes: >> >> > On Tue, Jan 5, 2021 at 9:52 PM Barry Smith <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> >> >> >> Ah, -snes_fd_color so it was already using finite differencing with >> >> coloring to compute the Jacobian which explains why the differences below >> >> are exactly zero. >> >> >> >> Implicit time-step schemes essentially add terms like I/dt to the >> >> Jacobian evaluation (and the function defining the ODE) so for tiny >> >> time-steps the nonlinear system gets easier and easier to solve (the >> >> nonlinear function becomes linear) But we didn't see that with your >> >> earlier >> >> run where dt 3.72529e-13 (which is absurdly small). for tiny time-steps >> >> SNES still made no progress. It is hard to understand how this is >> >> possible, >> >> regardless of the problem you are solving. >> >> >> >> I would next run the code with valgrind to insure there are no issues of >> >> memory corruption or un-initialized data. >> >> >> >> How are you computing >> >> >> >> (dp/dt)*(Pxx+Pyy+Pzz) >> >> >> >> >> >> That is, how are you computing Pxx etc? >> >> >> >> Are you using finite elements for the U and P model? Exactly what >> >> elements? >> >> >> > >> > I agree with Barry. This does not seem to make sense, so I would expect >> > some kind of inconsistent discretization, or other >> > mathematical problem which makes your system unsolvable. >> >> Try -mat_fd_type ds before ruling out sensitivity to differencing parameter. >> <valgrind-out.txt> > > <valgrind-5.txt>
