March 2014 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] getting data out of a PetscFE simulation
by Matthew Knepley 31 Mar '14

31 Mar '14

On Mon, Mar 31, 2014 at 9:27 AM, David Fuentes <fuentesdt(a)gmail.com> wrote: > Hi, > > I'm trying to get DMPlex to solve and display with Dirichlet boundary > conditions. > > My global and local solution vectors are of different sizes. The length > difference is the number of nodes read from the nodeset read in the exodus > file. > I am able to project the initial solution/boundary data that I want with > with VecSetValuesSection. The initial condition looks ok with the global > solution > in the viewer. However, I seem to be losing the dirichlet boundary data on > the solve ? I'm trying to use the suggested global to local scattering on > the output. > I have just worked all this out in 'next', and most of it is in 'master' now. I will talk through the process 1) Suppose you view a global vector, either VTK or HDF5 2) PETSc maps this to a local vector, and calls the local version, which is the same as viewing a local vector 3) PETSc will insert the correct boundary values (via DMPlexInsertBoundaryValuesFEM) if you specify them using the Section interface + DMAddBoundary(). Otherwise, you can view a local vector with the correct boundary values. 4) A scatter is created to a global vector including the boundary values 5) This expanded global vector is passes to the normal HDF5/VTK routines It is still a little rough, but it should not be much effort to get it working the way you want. Matt > { > > > > Vec localX; > > > > PetscSection section; > > > > PetscInt vStart, vEnd, v ; > > DMGetLocalVector(dm, &localX); > DMGetDefaultSection(dm, &section); > > DMPlexGetDepthStratum(dm, 0, &vStart, &vEnd); > for (v = vStart; v < vEnd; ++v) { > PetscScalar bcData = 101.0; > VecSetValuesSection(localX, section, v, &bcData , > INSERT_BC_VALUES); > } > DMRestoreLocalVector(dm, &localX); > DMLocalToGlobalBegin(dm, localX, INSERT_VALUES, u); > DMLocalToGlobalEnd(dm, localX, INSERT_VALUES, u); > > PetscViewer viewer; > char vtkfilename[PETSC_MAX_PATH_LEN] = > "initialcondition.vtk"; > ierr = > PetscViewerVTKOpen(PETSC_COMM_WORLD,vtkfilename,FILE_MODE_WRITE,&viewer);CHKERRQ(ierr); > ierr = VecView(u,viewer);CHKERRQ(ierr); > ierr = PetscViewerDestroy(&viewer);CHKERRQ(ierr) > } > > . > . > ierr = SNESSolve(snes, NULL, u);CHKERRQ(ierr); > . > . > > if (write_output) { > PetscViewer viewer; > const char *name; > Vec lv; > DMGetLocalVector(dm, &lv); > ierr = PetscObjectGetName((PetscObject) u,&name);CHKERRQ(ierr); > ierr = PetscObjectSetName((PetscObject) lv, name);CHKERRQ(ierr); > ierr = DMGlobalToLocalBegin(dm, u, INSERT_VALUES, lv);CHKERRQ(ierr); > ierr = DMGlobalToLocalEnd(dm, u, INSERT_VALUES, lv);CHKERRQ(ierr); > char vtkfilename[PETSC_MAX_PATH_LEN] = "solution.vtk"; > ierr = > PetscViewerVTKOpen(PETSC_COMM_WORLD,vtkfilename,FILE_MODE_WRITE,&viewer);CHKERRQ(ierr); > ierr = VecView(lv,viewer);CHKERRQ(ierr); > ierr = PetscViewerDestroy(&viewer);CHKERRQ(ierr); > ierr = DMRestoreLocalVector(dm, &lv);CHKERRQ(ierr); > } > > > > On Wed, Jan 29, 2014 at 2:04 PM, Geoffrey Irving <irving(a)naml.us> wrote: > >> On Wed, Jan 29, 2014 at 12:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> > Local vectors are supposed to be just that: local. VecViewing a local >> vector and expecting it to be parallel is perverse. So we need a real >> interface. >> > >> > Placing 1.0 on the diagonal (and don't assemble into those rows and >> columns) is the common way to deal with Dirichlet boundary nodes. See ex48 >> for one example. I have written about this in a few places; I can find the >> more complete description when I have a keyboard. >> >> I'll look forward to the improved interface. For better or worse, I'd >> like to be able to view simulations in the near future, so it looks >> like I have to go with Matt's perverse but working version now. >> >> Geoffrey >> >> > On January 29, 2014 12:53:26 PM MST, Geoffrey Irving <irving(a)naml.us> >> wrote: >> >>On Wed, Jan 29, 2014 at 11:36 AM, Jed Brown <jed(a)jedbrown.org> wrote: >> >>> Matt's sample code doesn't set it either. We need to fix (and the >> >>*only* acceptable fix if that VecView always does the right thing, >> >>because we have to be able to call it in analysis settings that know >> >>nothing about your discretization). >> >> >> >>Matt's sample code doesn't set it either, but for Matt's sample code I >> >>know where to insert the one line call to DMPlexProjectFunctionLocal. >> >>For your version I never have explicit access to the local vector, so >> >>I can't insert the fix. >> >> >> >>> The problem is that some vectors reside in a homogeneous space (e.g. >> >>increments and eigenvectors) while others reside in the inhomogeneous >> >>space (solutions). We can add a flag or BC attribute on the vector to >> >>this effect, but this (and slip conditions) was the issue that led me >> >>to conclude that removing boundary nodes was mostly a false economy. >> >> >> >>To leave the boundary conditions in, we would need efficient support >> >>for a very large, very sparse MatNullSpace. This is doable via >> >>shells, but is it easy to do in a way that doesn't interfere with the >> >>user's other null spaces? >> >> >> >>Geoffrey >> > >> > > -- 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

1 0

Re: [petsc-dev] getting data out of a PetscFE simulation
by David Fuentes 31 Mar '14

31 Mar '14

Hi, I'm trying to get DMPlex to solve and display with Dirichlet boundary conditions. My global and local solution vectors are of different sizes. The length difference is the number of nodes read from the nodeset read in the exodus file. I am able to project the initial solution/boundary data that I want with with VecSetValuesSection. The initial condition looks ok with the global solution in the viewer. However, I seem to be losing the dirichlet boundary data on the solve ? I'm trying to use the suggested global to local scattering on the output. { Vec localX; PetscSection section; PetscInt vStart, vEnd, v ; DMGetLocalVector(dm, &localX); DMGetDefaultSection(dm, &section); DMPlexGetDepthStratum(dm, 0, &vStart, &vEnd); for (v = vStart; v < vEnd; ++v) { PetscScalar bcData = 101.0; VecSetValuesSection(localX, section, v, &bcData , INSERT_BC_VALUES); } DMRestoreLocalVector(dm, &localX); DMLocalToGlobalBegin(dm, localX, INSERT_VALUES, u); DMLocalToGlobalEnd(dm, localX, INSERT_VALUES, u); PetscViewer viewer; char vtkfilename[PETSC_MAX_PATH_LEN] = "initialcondition.vtk"; ierr = PetscViewerVTKOpen(PETSC_COMM_WORLD,vtkfilename,FILE_MODE_WRITE,&viewer);CHKERRQ(ierr); ierr = VecView(u,viewer);CHKERRQ(ierr); ierr = PetscViewerDestroy(&viewer);CHKERRQ(ierr) } . . ierr = SNESSolve(snes, NULL, u);CHKERRQ(ierr); . . if (write_output) { PetscViewer viewer; const char *name; Vec lv; DMGetLocalVector(dm, &lv); ierr = PetscObjectGetName((PetscObject) u,&name);CHKERRQ(ierr); ierr = PetscObjectSetName((PetscObject) lv, name);CHKERRQ(ierr); ierr = DMGlobalToLocalBegin(dm, u, INSERT_VALUES, lv);CHKERRQ(ierr); ierr = DMGlobalToLocalEnd(dm, u, INSERT_VALUES, lv);CHKERRQ(ierr); char vtkfilename[PETSC_MAX_PATH_LEN] = "solution.vtk"; ierr = PetscViewerVTKOpen(PETSC_COMM_WORLD,vtkfilename,FILE_MODE_WRITE,&viewer);CHKERRQ(ierr); ierr = VecView(lv,viewer);CHKERRQ(ierr); ierr = PetscViewerDestroy(&viewer);CHKERRQ(ierr); ierr = DMRestoreLocalVector(dm, &lv);CHKERRQ(ierr); } On Wed, Jan 29, 2014 at 2:04 PM, Geoffrey Irving <irving(a)naml.us> wrote: > On Wed, Jan 29, 2014 at 12:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Local vectors are supposed to be just that: local. VecViewing a local > vector and expecting it to be parallel is perverse. So we need a real > interface. > > > > Placing 1.0 on the diagonal (and don't assemble into those rows and > columns) is the common way to deal with Dirichlet boundary nodes. See ex48 > for one example. I have written about this in a few places; I can find the > more complete description when I have a keyboard. > > I'll look forward to the improved interface. For better or worse, I'd > like to be able to view simulations in the near future, so it looks > like I have to go with Matt's perverse but working version now. > > Geoffrey > > > On January 29, 2014 12:53:26 PM MST, Geoffrey Irving <irving(a)naml.us> > wrote: > >>On Wed, Jan 29, 2014 at 11:36 AM, Jed Brown <jed(a)jedbrown.org> wrote: > >>> Matt's sample code doesn't set it either. We need to fix (and the > >>*only* acceptable fix if that VecView always does the right thing, > >>because we have to be able to call it in analysis settings that know > >>nothing about your discretization). > >> > >>Matt's sample code doesn't set it either, but for Matt's sample code I > >>know where to insert the one line call to DMPlexProjectFunctionLocal. > >>For your version I never have explicit access to the local vector, so > >>I can't insert the fix. > >> > >>> The problem is that some vectors reside in a homogeneous space (e.g. > >>increments and eigenvectors) while others reside in the inhomogeneous > >>space (solutions). We can add a flag or BC attribute on the vector to > >>this effect, but this (and slip conditions) was the issue that led me > >>to conclude that removing boundary nodes was mostly a false economy. > >> > >>To leave the boundary conditions in, we would need efficient support > >>for a very large, very sparse MatNullSpace. This is doable via > >>shells, but is it easy to do in a way that doesn't interfere with the > >>user's other null spaces? > >> > >>Geoffrey > > >

1 0

Re: [petsc-dev] Options setup logic is broken
by Barry Smith 30 Mar '14

30 Mar '14

On Mar 30, 2014, at 8:43 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Matthew Knepley <knepley(a)gmail.com> writes: > >> I have a PetscOptionsBegin/End() block. Inside, we create some contexts, >> which >> have PetscOptionsHead/Tail() blocks. This used to work fine, but I started >> getting >> a bizarre error. >> >> It turned out that the part of the function after OptionsTail() had not >> run. This was >> because the PetscOptionsPublishCount was > 1. This happened because I had >> moved the creation of a PetscObject inside the Begin/End block. This was the >> first object created, so a ThreadComm communicator was created. This called >> PetscThreadCommSetNThreads(), which called its own OptionsBegin/End block >> which screwed up mine. > > I've been bit by this lack of nesting on a few occasions. The solution > we discussed is to make it safe to nest. > > I am not sure that the current implicit nature of ThreadComm is a good > idea. The way threadcomm interacts with the system is very different > From all the normal PetscObjects, so it may make sense to handle it > differently.\ Paul will be starting in a month so start thinking about how you what threadcomm redesigned. Barry

1 0

Re: [petsc-dev] Options setup logic is broken
by Jed Brown 30 Mar '14

30 Mar '14

Matthew Knepley <knepley(a)gmail.com> writes: > I have a PetscOptionsBegin/End() block. Inside, we create some contexts, > which > have PetscOptionsHead/Tail() blocks. This used to work fine, but I started > getting > a bizarre error. > > It turned out that the part of the function after OptionsTail() had not > run. This was > because the PetscOptionsPublishCount was > 1. This happened because I had > moved the creation of a PetscObject inside the Begin/End block. This was the > first object created, so a ThreadComm communicator was created. This called > PetscThreadCommSetNThreads(), which called its own OptionsBegin/End block > which screwed up mine. I've been bit by this lack of nesting on a few occasions. The solution we discussed is to make it safe to nest. I am not sure that the current implicit nature of ThreadComm is a good idea. The way threadcomm interacts with the system is very different From all the normal PetscObjects, so it may make sense to handle it differently.

1 0

Options setup logic is broken
by Matthew Knepley 30 Mar '14

30 Mar '14

I have a PetscOptionsBegin/End() block. Inside, we create some contexts, which have PetscOptionsHead/Tail() blocks. This used to work fine, but I started getting a bizarre error. It turned out that the part of the function after OptionsTail() had not run. This was because the PetscOptionsPublishCount was > 1. This happened because I had moved the creation of a PetscObject inside the Begin/End block. This was the first object created, so a ThreadComm communicator was created. This called PetscThreadCommSetNThreads(), which called its own OptionsBegin/End block which screwed up mine. This is crazy. Matt -- 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

1 0

pls bearing
by seiko-bearing 29 Mar '14

29 Mar '14

Dear sir Good Day Kind greetings from Alice! We can provide a lots of brand bearing,including:SKF FAG KOYO NTN NSK TIMKEN URB ZKL DPI. I`d love to give you detailed info and best price if you have any interests.Sample supplied to test quality. My company can provide you with, a variety of complicated model, please believe me the strength of the company. Do you have any need, please send email to me, you are sure to get the most preferential price. We can provide you with free samples. Looking forward to hear from you soon. Free, bearing samples and Courier charge Many thanks, Alice Email: seiko-bearing(a)vip.163.com

1 0

Re: [petsc-dev] [GPU] src/ksp/ksp/examples/tutorials/ex9 fails with mpirun -np 2
by Karl Rupp 28 Mar '14

28 Mar '14

Hi Pierre, I could reproduce the problem, but I could also verify that the problem you ran into was due to a currently unsupported block-Jacobi preconditioner. That is, if you first comment the KSPSolve for the ksp2 object in ex9, recompile ex9, and then run $> mpiexec -np 2 ./ex9 -ksp_monitor -mat_type aijcusp -vec_type cusp -pc_type none thinks should work out. This may also be applicable to your case: Give it a try with -pc_type none and let us whether the problem with VecSetValues remains. (The use of no preconditioner is certainly not great, but at least it may give you a first result) Best regards, Karli On 03/26/2014 06:38 PM, Projet_TRIOU wrote: > Hello all, > > My parallel code is really near to run using GPU device > thanks to PETSc but I am struggling with the best way > to fill the PETSc vectors in order in runs on CPU & GPU. > > I was using in the past, VecCreateMPIWithArray, to > create vector but I had trouble with it on GPU. > > So I followed the example in the src/ksp/ksp/examples/tutorials/ex2.c > and create now the vectors like this: > > // Build x > ierr = VecCreate(PETSC_COMM_WORLD,&SecondMembrePetsc_); check(ierr); > ierr = VecSetSizes(SecondMembrePetsc_, nb_rows, nb_rows_tot); > check(ierr); > ierr = VecSetFromOptions(SecondMembrePetsc_); check(ierr); > // Build b > ierr = VecDuplicate(SecondMembrePetsc_,&SolutionPetsc_);check(ierr); > > And fills it with VecSetValues function. It runs well on CPU and > GPU but crashed only in parallel on GPU. It I use VecSet instead of > VecSetValues, it didn't crash (but of course VecSet is not enough > for me :-) > > I tried to find an example to reproduce for you the problem, and I > think src/ksp/ksp/examples/tutorials/ex9 (it is usingVecSetValues,) > is a good one. > > Or did I miss something (I also try VecPlaceArray/VecRestoreArray > but without success on GPU) ? > > Thanks, and yes you are right, "WARNING: Using GPUs effectively is > difficult!" :-) > > Pierre > > sitre.intra.cea.fr:/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/petsc/linux_opt/src/ksp/ksp/examples/tutorials > > ./ex9 -ksp_monitor > 0 KSP Residual norm 6.612932697792e+00 > 1 KSP Residual norm 4.261830032389e-01 > 2 KSP Residual norm 2.121746090851e-02 > 3 KSP Residual norm 1.233779841608e-03 > 4 KSP Residual norm 1.265903168531e-05 > 0 KSP Residual norm 1.309416176382e-05 > 0 KSP Residual norm 1.404919664063e-05 > > sitre.intra.cea.fr:/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/petsc/linux_opt/src/ksp/ksp/examples/tutorials > > mpiexec -np 2 ./ex9 -ksp_monitor > 0 KSP Residual norm 2.496821857304e+02 > 1 KSP Residual norm 4.522206074831e+01 > 2 KSP Residual norm 1.959482408314e+01 > 3 KSP Residual norm 7.002013703407e+00 > 4 KSP Residual norm 2.144105201713e+00 > 5 KSP Residual norm 1.780095080270e-01 > 6 KSP Residual norm 5.642702243268e-02 > 7 KSP Residual norm 6.439343992306e-03 > 8 KSP Residual norm 3.012756374415e-04 > Norm of error 0.000249108, Iterations 8 > Norm of error 0.000715584, Iterations 6 > 0 KSP Residual norm 3.422287562824e-04 > Norm of error 0.000249108, Iterations 0 > Norm of error 0.000192805, Iterations 7 > 0 KSP Residual norm 4.140588954098e-04 > Norm of error 0.000249108, Iterations 0 > Norm of error 0.000109507, Iterations 7 > > sitre.intra.cea.fr:/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/petsc/linux_opt/src/ksp/ksp/examples/tutorials > > ./ex9 -ksp_monitor -mat_type aijcusp -vec_type cusp > 0 KSP Residual norm 6.612932697792e+00 > 1 KSP Residual norm 4.261830032389e-01 > 2 KSP Residual norm 2.121746090851e-02 > 3 KSP Residual norm 1.233779841608e-03 > 4 KSP Residual norm 1.265903168531e-05 > 0 KSP Residual norm 1.309416176403e-05 > 0 KSP Residual norm 1.404919664088e-05 > > sitre.intra.cea.fr:/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/petsc/linux_opt/src/ksp/ksp/examples/tutorials > > mpiexec -np 2 ./ex9 -ksp_monitor -mat_type aijcusp -vec_type cusp > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, > probably memory access out of range > [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger > [0]PETSC ERROR: or see > http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind[0]PETSC > ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to > find memory corruption errors > [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, > and run > [0]PETSC ERROR: to get more information on the crash. > [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > [0]PETSC ERROR: Signal received > [0]PETSC ERROR: See > http://http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble > shooting. > [0]PETSC ERROR: Petsc Development GIT revision: v3.4.4-3713-g576f62e > GIT Date: 2014-03-23 15:59:15 -0500 > [0]PETSC ERROR: ./ex9 on a linux_opt named sitre.intra.cea.fr by triou > Wed Mar 26 18:32:34 2014 > [0]PETSC ERROR: Configure options > --prefix=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/petsc/linux_opt > --with-single-library --with-shared-libraries=0 --with-debugging=0 > --with-errorchecking=1 --COPTFLAGS=" -O3 -fPIC " --CXXOPTFLAGS=" -O3 > -fPIC " --FOPTFLAGS=" -O3 -fPIC " --with-fortran=yes --with-clean=1 > --download-scalapack=../scalapack-2.0.2.tgz > --download-mumps=../MUMPS_4.10.0-p3.tar.gz --download-superlu_dist=yes > --download-parmetis=../parmetis-4.0.2-p4.tar.gz > --download-metis=../metis-5.0.2-p3.tar.gz > --download-ptscotch=../ptscotch.tar.gz > --download-hypre=../hypre-2.9.1a.tar.gz > --with-valgrind-include=/work/triou/git/petsc-dev/Trio_U/exec/valgrind/include > --with-blas-lapack-dir=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBLAPACK --with-cuda=1 > --with-cuda-dir=/work/triou/git/petsc-dev/Trio_U/exec/cuda5.5 > --with-cusp=1 > --with-cusp-dir=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/cusplibrary-0.4.0 > --with-thrust=1 --with-cuda-arch=sm_21 --with-ssl=0 > --with-mpi-dir=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBMPI/mpich > --with-x=1 > [0]PETSC ERROR: #1 User provided function() line 0 in unknown file > [1]PETSC ERROR: > ------------------------------------------------------------------------ > [1]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, > probably memory access out of range > [1]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger > [1]PETSC ERROR: or see > http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind[1]PETSC > ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to > find memory corruption errors > [1]PETSC ERROR: configure using --with-debugging=yes, recompile, link, > and run > [1]PETSC ERROR: application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 > to get more information on the crash. > [1]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > [1]PETSC ERROR: Signal received > [1]PETSC ERROR: See > http://http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble > shooting. > [1]PETSC ERROR: Petsc Development GIT revision: v3.4.4-3713-g576f62e > GIT Date: 2014-03-23 15:59:15 -0500 > [1]PETSC ERROR: ./ex9 on a linux_opt named sitre.intra.cea.fr by triou > Wed Mar 26 18:32:34 2014 > [1]PETSC ERROR: Configure options > --prefix=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/petsc/linux_opt > --with-single-library --with-shared-libraries=0 --with-debugging=0 > --with-errorchecking=1 --COPTFLAGS=" -O3 -fPIC " --CXXOPTFLAGS=" -O3 > -fPIC " --FOPTFLAGS=" -O3 -fPIC " --with-fortran=yes --with-clean=1 > --download-scalapack=../scalapack-2.0.2.tgz > --download-mumps=../MUMPS_4.10.0-p3.tar.gz --download-superlu_dist=yes > --download-parmetis=../parmetis-4.0.2-p4.tar.gz > --download-metis=../metis-5.0.2-p3.tar.gz > --download-ptscotch=../ptscotch.tar.gz > --download-hypre=../hypre-2.9.1a.tar.gz > --with-valgrind-include=/work/triou/git/petsc-dev/Trio_U/exec/valgrind/include > --with-blas-lapack-dir=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBLAPACK --with-cuda=1 > --with-cuda-dir=/work/triou/git/petsc-dev/Trio_U/exec/cuda5.5 > --with-cusp=1 > --with-cusp-dir=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBPETSC/cusplibrary-0.4.0 > --with-thrust=1 --with-cuda-arch=sm_21 --with-ssl=0 > --with-mpi-dir=/work/triou/git/petsc-dev/Trio_U/lib/src/LIBMPI/mpich > --with-x=1 > [1]PETSC ERROR: #1 User provided function() line 0 in unknown file > application called MPI_Abort(MPI_COMM_WORLD, 59) - process 1 > > > > -- > *Trio_U support team* > Marthe ROUX (01 69 08 00 02) Saclay > Pierre LEDAC (04 38 78 91 49) Grenoble

1 0

Re: [petsc-dev] We need to cleanup viewers
by Jed Brown 27 Mar '14

27 Mar '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > You shouldn’t be allowed to start implementing a complicated nested > “framework system” until you clearly understand how you are going > to debug in it. The community should just not tolerate that kind of > crap. Good luck with that.

1 0

Re: [petsc-dev] We need to cleanup viewers
by Barry Smith 27 Mar '14

27 Mar '14

On Mar 27, 2014, at 5:22 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> On Mar 27, 2014, at 5:03 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >>> Barry Smith <bsmith(a)mcs.anl.gov> writes: >>>> If a user calls XXX() and it doesn’t do what they expect, how do >>>> they figure out what is wrong? It is called debugging and usually >>>> it is because what they expect is not what it does. >>> >>> I have to say, my first instinct in such cases, especially when working >>> with an unfamiliar code base, is that the line invoking the viewer is >>> never reached >> >> Trivia to check in the debugger. > > Yes, but already cumbersome when the front-end is Python, the program is > launched through a script that always creates at least 9 processes, the > build system doesn't support simultaneous debug and optimized installs, > and rebuilds take hours. Suddenly you're jumping through hoops (each > one manageable if disconcerting) for what should have been a 10-second > task. I don't understand why people bring such things upon them, but > the things we shrug off as 10-second queries are not always. Yes, it's > "their" own damn fault for building a monstrosity, but there is > sometimes amazing value in simple reasoning about user code. You shouldn’t be allowed to start implementing a complicated nested “framework system” until you clearly understand how you are going to debug in it. The community should just not tolerate that kind of crap. > >>> Sometimes we want XXView(X,V) to mean "Hey X, anything you feel like >>> talking about?" and other times we mean "X, serialize yourself!” >> >> Maybe this is related to the specific type of viewer and even >> format. > > Indeed, some sort of attribute of the viewer. It may be tricky to know > which semantic is best in all cases, but I think many are clear. > >> Also it is related to either 1) serialize yourself so you can be >> totally recreated (true serialization) versus 2) serialize enough >> of yourself so I can visualize you. We usually do 2) currently and >> in that case it is reasonable sometimes to not view everything.

1 0

Re: [petsc-dev] We need to cleanup viewers
by Jed Brown 27 Mar '14

27 Mar '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > On Mar 27, 2014, at 5:03 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> Barry Smith <bsmith(a)mcs.anl.gov> writes: >>> If a user calls XXX() and it doesn’t do what they expect, how do >>> they figure out what is wrong? It is called debugging and usually >>> it is because what they expect is not what it does. >> >> I have to say, my first instinct in such cases, especially when working >> with an unfamiliar code base, is that the line invoking the viewer is >> never reached > > Trivia to check in the debugger. Yes, but already cumbersome when the front-end is Python, the program is launched through a script that always creates at least 9 processes, the build system doesn't support simultaneous debug and optimized installs, and rebuilds take hours. Suddenly you're jumping through hoops (each one manageable if disconcerting) for what should have been a 10-second task. I don't understand why people bring such things upon them, but the things we shrug off as 10-second queries are not always. Yes, it's "their" own damn fault for building a monstrosity, but there is sometimes amazing value in simple reasoning about user code. >> Sometimes we want XXView(X,V) to mean "Hey X, anything you feel like >> talking about?" and other times we mean "X, serialize yourself!” > > Maybe this is related to the specific type of viewer and even > format. Indeed, some sort of attribute of the viewer. It may be tricky to know which semantic is best in all cases, but I think many are clear. > Also it is related to either 1) serialize yourself so you can be > totally recreated (true serialization) versus 2) serialize enough > of yourself so I can visualize you. We usually do 2) currently and > in that case it is reasonable sometimes to not view everything.

1 0