[petsc-users] VecView to hdf5 broken for large (complex) vectors

[Smith, Barry F.]

  Funny you should ask, I just found the bug. 

> On Apr 16, 2019, at 9:47 PM, Sajid Ali <sajidsyed2021 at u.northwestern.edu> wrote:
> 
> Quick question : To drop a print statement at the required location, I need to modify the source code, build petsc from source and compile with this new version of petsc, right or is there an easier way? (Just to confirm before putting in the effort)

   Yes. But perhaps spack has a way to handle this as well; it should. Satish? If you can get spack to use the git repository then you could edit in that and somehow have spack rebuild using your edited repository.

   Barry
> 
> On Tue, Apr 16, 2019 at 8:42 PM Smith, Barry F. <bsmith at mcs.anl.gov> wrote:
> 
>   Dang, I  ranted too soon.
> 
>   I built mpich  using spack (master branch) and a very old Gnu C compiler and it produced valgrind clean code. Spack definitely is not passing the --enable-g=meminit to MPICH ./configure so this version of MPICH valgrind must be clean by default? MPICH's ./configure has
> 
> meminit  - Preinitialize memory associated structures and unions to
>                    eliminate access warnings from programs like valgrind
> 
> The default for enable-g is most and
> 
> most|yes)
>         perform_memtracing=yes
>         enable_append_g=yes
>         perform_meminit=yes
>         perform_dbgmutex=yes
>         perform_mutexnesting=yes
>         perform_handlealloc=yes
>         perform_handle=yes
> 
> So it appears that at least some releases of MPICH are suppose to be valgrind clean by default ;).
> 
> Looking back at Sajid's valgrind output more carefully
> 
> Conditional jump or move depends on uninitialised value(s)
> ==15359==    at 0x1331069A: __intel_sse4_strncmp (in /opt/intel/compilers_and_libraries_2019.1.144/linux/compiler/lib/intel64_lin/libintlc.so.5)
> 
> is the only valgrind error. Which I remember seeing from using Intel compilers for a long time, nothing to do with MPICH
> 
> Thus I conclude that Sajid's code is actually valgrind clean; and I withdraw my rant about MPICH/spack
> 
> Barry
> 
> 
> 
> > On Apr 16, 2019, at 5:13 PM, Smith, Barry F. <bsmith at mcs.anl.gov> wrote:
> >
> >
> >  So valgrind is printing all kinds of juicy information about uninitialized values but it is all worthless because MPICH was not built by spack to be valgrind clean. We can't know if any of the problems valgrind flags are real. MPICH needs to be configured with the option --enable-g=meminit to be valgrind clean. PETSc's --download-mpich always installs a valgrind clean MPI.
> >
> > It is unfortunate Spack doesn't provide a variant of MPICH that is valgrind clean; actually it should default to valgrind clean MPICH.
> >
> >  Barry
> >
> >
> >
> >
> >> On Apr 16, 2019, at 2:43 PM, Sajid Ali via petsc-users <petsc-users at mcs.anl.gov> wrote:
> >>
> >> So, I tried running the debug version with valgrind to see if I can find the chunk size that's being set but I don't see it. Is there a better way to do it ?
> >>
> >> `$ mpirun -np 32 valgrind ./ex_ms -prop_steps 1 -info &> out`. [The out file is attached.]
> >> <out>
> >
> 
> 
> 
> -- 
> Sajid Ali
> Applied Physics
> Northwestern University