On Thu, Oct 27, 2011 at 00:16, Paul Sicsic <paul.sicsic at polytechnique.edu>wrote:
> The X you passed in is not a valid Mat (we could see that from the earlier >> call). More specifically, according to valgrind, it is uninitialized memory. >> The shift is still infinite coming into this function, which I don't >> understand. >> >> Why do you say the X matrix is not valid ? > If I run the program with -mat_view, our Mass (AppCtx%M) and rigidity > matrix (AppCTx%K) are assembled. > The Mat that makes it into MatAXPY is not valid. What does your code look like that makes that call? > > >> From the singularity at 0, it looks like perhaps the initial time step >> size is being set to zero. Next time you get a stack trace, can you on >> ts->time_step? >> > Yes, it should. > > tssolve_ (ts=0x7fff42d866e0, x=0x7fff42d86388, ftime=0x7fff42d866f0, > __ierr=0x7fff42d85adc) at > /opt/HPC/petsc-dev/src/ts/interface/ftn-auto/tsf.c:397 > 397 (Vec)PetscToPointer((x) ),ftime); > (gdb) p ts->time_step > $1 = 6.9531990170672068e-310 > > Should ts->time_step be inizialized entering TSSolve ? > > We had called (As in example ex22f) : > Call TSSetInitialTimeStep(AppCtx%TS, 0.0, .01, ierr); CHKERRQ(iErr) > Call TSSetFromOptions(AppCtx%TS, iErr); CHKERRQ(iErr) > This is one reason why I HATE, HATE, HATE Fortran. When you pass the literals 0.0 and .01, they are passed as single instead of double precision. You need to define variables to hold these values: PetscReal zero,dt zero = 0.0 dt = .01 call TSSetInitialTimeStep(AppCtx%TS, zero, dt, ierr) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111027/7dad600d/attachment.html>
