[petsc-dev] problem with hdf5 plots

Mark Adams mfadams at lbl.gov
Sat Oct 22 22:28:21 CDT 2016


Toby, this problem is comming from Forest. It appears Forest takes a Vecs
viewer during a solve (I don't see where else it could be). This is why the
code worked before the solve, it was calling different methods than after
the solve. Here is the problematic stack trace.  In tracing what was
written to the HDF5 file it looks like the only difference between the
original (good) and the Forest method (bad) was that a vector of size one,
with the time, was written. Actually it is written twice. (And I do see
time stuff in Visit.)

Do you think you could take a look at this and see if you come up with a
solution (like disable the time stuff) and I could test it or you can in
branch mark/feature-picell:

src/dm/impls/picell/examples/tutorials > make ex3
src/dm/impls/picell/examples/tutorials > make runex3

and you should get a ex3.xmf file that Visit will show has all zero data.

Thanks,

#0  VecView (vec=0x1041b4a60, viewer=0x1041e6660) at
/Users/markadams/Codes/petsc/src/vec/vec/interface/vector.c:583
#1  0x000000010006ca6e in PetscObjectView (obj=0x1041b4a60,
viewer=0x1041e6660) at
/Users/markadams/Codes/petsc/src/sys/objects/destroy.c:106
#2  0x0000000100093033 in PetscObjectViewFromOptions (obj=0x1041b4a60,
bobj=warning: (Internal error: pc 0x0 in read in psymtab, but not in
symtab.)

0x0, optionname=0x101d243a6 "-vec_view") at
/Users/markadams/Codes/petsc/src/sys/objects/options.c:2810
#3  0x00000001003119b0 in VecViewFromOptions (A=0x1041b4a60, B=warning:
(Internal error: pc 0x0 in read in psymtab, but not in symtab.)

0x0, name=0x101d243a6 "-vec_view") at
/Users/markadams/Codes/petsc/include/petscvec.h:129
#4  0x00000001003117ef in VecAssemblyEnd (vec=0x1041b4a60) at
/Users/markadams/Codes/petsc/src/vec/vec/interface/vector.c:193
#5  0x0000000100da814a in DMSequenceView_HDF5 (dm=0x1040e1260,
seqname=0x101d6ed54 "time", seqnum=2, value=3.5868277344680086,
viewer=0x104137a60) at
/Users/markadams/Codes/petsc/src/dm/impls/plex/plexhdf5.c:32
#6  0x0000000100da683b in VecView_Plex_Local_HDF5 (v=0x1041f2a60,
viewer=0x104137a60) at
/Users/markadams/Codes/petsc/src/dm/impls/plex/plexhdf5.c:96
#7  0x0000000100c4d522 in VecView_Plex_Local (v=0x1041f2a60,
viewer=0x104137a60) at
/Users/markadams/Codes/petsc/src/dm/impls/plex/plex.c:88
#8  0x0000000100da8a06 in VecView_Plex_HDF5 (v=0x104b3c860,
viewer=0x104137a60) at
/Users/markadams/Codes/petsc/src/dm/impls/plex/plexhdf5.c:169
#9  0x0000000100c50dd2 in VecView_Plex (v=0x104b3c860, viewer=0x104137a60)
at /Users/markadams/Codes/petsc/src/dm/impls/plex/plex.c:203
#10 0x0000000100b509d4 in VecView_p8est (vec=0x104b3c860,
viewer=0x104137a60) at
/Users/markadams/Codes/petsc/src/dm/impls/forest/p4est/pforest.c:4332
#11 0x0000000100317a13 in VecView (vec=0x104b3c860, viewer=0x104137a60) at
/Users/markadams/Codes/petsc/src/vec/vec/interface/vector.c:619
#12 0x00000001000216a1 in viewDMVec ()
#13 0x000000010001a074 in main ()


On Sat, Oct 22, 2016 at 1:51 PM, Mark Adams <mfadams at lbl.gov> wrote:

> I have tried a million things but I have a strange error that I am not
> fixing and wanted to see if anyone has anh ideas.
>
> I am printing an 8 field cell centered 3D field (960 variables total). I
> initialize the field and print it. It looks perfect. I then do a TSSolve
> and it looks fine except all the data is 0.0.
>
> But If I do a VecView to standard just before the HDF5 print of the
> vector, it has good looking data. And I added a print statement in pdvec.c
> before the call to HDF5 like:
>
> int i;
> PetscPrintf(PETSC_COMM_WORLD,"%s call PetscStackCallHDF5 xin->map->n=%6D:
> ",__FUNCT__,xin->map->n);
> for (i=0;i<xin->map->n && i<3;i++){
>  PetscPrintf(PETSC_COMM_WORLD,"%10.2e ",x[i]);
> }
> PetscPrintf(PETSC_COMM_WORLD,"\n");
>   PetscStackCallHDF5(H5Dwrite,(dset_id, memscalartype, memspace,
> filespace, plist_id, x));
>
> And this (appended) is what I get on one processor with valgrind. I see
> perfectly good data plus the time step data in the second call. There is a
> valgrind message in the first (good) call.
>
> I wonder if:  ${PETSC_DIR}/bin/petsc_gen_xdmf.py ex3.h5; is getting
> confused with the time data. Anyone know of a way to look at the .h5 (raw)
> data?
>
> Mark
>
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=   525:   5.01e+02
> 0.00e+00  -3.85e-16
> ==94708== Use of uninitialised value of size 8
> ==94708==    at 0x1019405BB: H5D__chunk_lookup (in ./ex3.arch-macosx-gnu-g)
> ==94708==    by 0x10195757A: H5D__chunk_collective_io (in
> ./ex3.arch-macosx-gnu-g)
> ==94708==    by 0x101959BAF: H5D__chunk_collective_write (in
> ./ex3.arch-macosx-gnu-g)
> ==94708==    by 0x101954E4A: H5Dwrite (in ./ex3.arch-macosx-gnu-g)
> ==94708==    by 0x100304C6B: VecView_MPI_HDF5 (pdvec.c:762)
> ==94708==    by 0x1002DEE52: VecView_Seq (bvec2.c:654)
> ==94708==    by 0x100317B55: VecView (vector.c:616)
> ==94708==    by 0x100DACCE6: DMPlexWriteCoordinates_HDF5_Static
> (plexhdf5.c:422)
> ==94708==    by 0x100DAA23A: DMPlexView_HDF5 (plexhdf5.c:519)
> ==94708==    by 0x100C60109: DMView_Plex (plex.c:829)
> ==94708==    by 0x1009DC80E: DMView (dm.c:851)
> ==94708==    by 0x100B505D1: DMView_HDF5_p8est (pforest.c:1417)
> ==94708==    by 0x100B3F8E8: DMView_p8est (pforest.c:1440)
> ==94708==    by 0x1009DC80E: DMView (dm.c:851)
> ==94708==    by 0x10006CCBD: PetscObjectView (destroy.c:106)
> ==94708==    by 0x100093282: PetscObjectViewFromOptions (options.c:2810)
> ==94708==    by 0x1000277BF: DMViewFromOptions (in ./ex3.arch-macosx-gnu-g)
> ==94708==    by 0x10001F7E1: viewDMVec (in ./ex3.arch-macosx-gnu-g)
> ==94708==    by 0x10001799F: main (in ./ex3.arch-macosx-gnu-g)
> ==94708==
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=  1664:   1.00e+00
> 2.97e-03  -1.90e-03
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=   960:   1.00e+00
> 2.97e-03  -1.90e-03
> 0 TS dt 1.79271 time 0.
> 1 TS dt 1.79271 time 1.79271
> 2 TS dt 1.79271 time 3.58542
> TS Object: 1 MPI processes
>   type: ssp
>   maximum steps=2
>   maximum time=1e+12
>   total number of nonlinear solver iterations=0
>   total number of nonlinear solve failures=0
>   total number of linear solver iterations=0
>   total number of rejected steps=0
>   using relative error tolerance of 0.0001,   using absolute error
> tolerance of 0.0001
>     Scheme: rks2
> CONVERGED_ITS at time 3.58542 after 2 steps
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=   525:   5.01e+02
> 0.00e+00  -3.85e-16
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=     1:   3.59e+00
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=     1:   3.59e+00
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=  1664:   1.02e+00
> 4.52e-04  -3.37e-03
> VecView_MPI_HDF5 call PetscStackCallHDF5 xin->map->n=   960:   1.02e+00
> 4.52e-04  -3.37e-03
> [0] done - cleanup
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161022/979c629f/attachment.html>


More information about the petsc-dev mailing list