December 2018 - petsc-dev - mailman3.cels.anl.gov

Faulty logic in MatHYPRESetPreallocation?
by Pierre Jolivet 17 Dec '18

17 Dec '18

Hello, I am not sure the hypre routines are called in the right order in MatHYPRESetPreallocation. Indeed, attached, you’ll find two Massif logs, one with the current order (massif.out.bad), and the other (massif.out.better) with the attached patch applied. In the former, you can see at the snapshot #31 that there is a call to hypre_CTAlloc in hypre_AuxParCSRMatrixInitialize (aux_parcsr_matrix.c:163). This means that hypre is allocating memory as if it was not aware of the number of nonzero per row, even though I supply in my application the two arrays dnnz and onnz. Am I missing something? Thanks, Pierre

1 0

Re: [petsc-dev] mkl_cpardiso.c warnings
by Matthew Knepley 15 Dec '18

15 Dec '18

Yep, we found these. I am going to make a PR. Thanks for reporting. Matt On Fri, Dec 14, 2018 at 9:17 PM Eric Chamberland via petsc-dev < petsc-dev(a)mcs.anl.gov> wrote: > Hi, > > I just noticed there are warnings at compile time for some mkl_cpardiso.c > routines: > > /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/petsc-master-debug/src/mat/impls/aij/mpi/mkl_cpardiso/mkl_cpardiso.c: In function ‘MatDestroy_MKL_CPARDISO’: > /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/petsc-master-debug/src/mat/impls/aij/mpi/mkl_cpardiso/mkl_cpardiso.c:236:7: warning: passing argument 16 of ‘cluster_sparse_solver’ from incompatible pointer type [enabled by default] > (int*)&mat_mkl_cpardiso->err); > > and some more, full log here: > > > http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.12.14.09h24m33… > > > and configure log: > > > http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.12.14.09h24m33… > > > Thanks, > > Eric > > > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

mkl_cpardiso.c warnings
by Eric Chamberland 14 Dec '18

14 Dec '18

Hi, I just noticed there are warnings at compile time for some mkl_cpardiso.c routines: /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/petsc-master-debug/src/mat/impls/aij/mpi/mkl_cpardiso/mkl_cpardiso.c: In function ‘MatDestroy_MKL_CPARDISO’: /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/petsc-master-debug/src/mat/impls/aij/mpi/mkl_cpardiso/mkl_cpardiso.c:236:7: warning: passing argument 16 of ‘cluster_sparse_solver’ from incompatible pointer type [enabled by default] (int*)&mat_mkl_cpardiso->err); and some more, full log here: http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.12.14.09h24m33… and configure log: http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.12.14.09h24m33… Thanks, Eric

1 0

Re: [petsc-dev] Checkpoint-restart with DMPlex objects
by Matthew Knepley 14 Dec '18

14 Dec '18

On Fri, Jul 20, 2018 at 5:34 AM Lawrence Mitchell <wence(a)gmx.li> wrote: > Dear petsc-dev, > > I'm once again revisiting doing "proper" checkpoint-restart cycles. I > would like to leverage the existing PETSc stuff for this as much as > possible, but I am a bit lost as to what is implemented, and what is > missing. > > I have: > > - A (distributed) DMPlex defining the topology > > - Some number of fields defined on this topology, each described by: > > - a Section (with a point permutation set) > - a Vec of coefficients > - Some extra information that describes what the coefficients mean, but > let's assume I know how to handle that. > > (Aside, for Vecs with a block size > 1, I actually have a section that > indexes the blocks, which probably means I need to unroll into an unblocked > version first). > Sections usually are {point --> {dofs}}. Not sure how it uses blocks instead of points. > I would like: > > - To be able to dump the DMPlex, and fields, on N processes > I think the current HDF5 does what you want. > - To be able to load the DMPlex, and fields, on P processes. In the first > instance, to get things going, I am happy if P=1. > I think this also works with arbitrary P, although the testing can be described as extremely thin. > For dumping, I think I can do DMView(dm) in PETSc "native" format, and > that will write out the topology in a global numbering. > I would use HDF5. > For the field coefficients, I can just VecView(vec). But there does not > appear to be any way of saving the Section so that I can actually attach > those coefficients to points in the mesh. > Hmm, I will check this right now. If it does not exist, I will write it. > I can do PetscSectionCreateGlobalSection(section), so that I have a the > global numbering for offsets, but presumably for the point numbering, I > need to convert the local chart into global point numbers using > DMPlexCreatePointNumbering? > No, all Sections use local points. We do not use global point numbers anywhere in Plex. > For load, I can do DMLoad(dm), which only loads on rank-0 for now. I do not think that is true. > Then VecLoad for the coefficients, and (presumably) a putative > PetscSectionLoad so that I can associate coefficients to points in the > topology. > Okay, I am remembering more now. I just use the PetscDS to automatically create the Section, and pray that it matches the Vec that we saved. This is a real design limitation, since the Section is associated with the DM not the Vec, you have to assume all stored Vecs were created with the default Section in the DM. Now, if this is true, then you could just load the Section, set it as the default for the DM, and load the Vec. > So it feels like the crucial part of this is a native (HDF5) based viewing > for PetscSection. > Yep. I thought this worked, but maybe I only decided it should work. > For each section (I'm ignoring fields, because those are just sections > anyway), there are two explicit, and one implicit, pieces of information: > > 1. The number of dofs per point > Yep. > 2. The offset of the dof (this is the global numbering) > No, you should store the local Section. You use the SF for the DM to automatically get the global section. > 3 (implicit). The association of the local chart numbering to the global > chart. > Above. > Saving the first two is easy, how best to save the last so that I can load > easily. My thought is to, for each point in the section chart, save a > three-tuple: (global-point-number, dofs-per-point, global-dof-number) > Hmm, I have to think a little bit more. Where are you at with this now? Matt > Then, I can easily read this data in and correctly map from the on-disk > coefficients into any section I might have built on the newly loaded DM. > > Does this all sound reasonable? Or have I missed either an existing > implementation, or other issues? > > Cheers, > > Lawrence -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] Tao unusable from complex??
by Munson, Todd 12 Dec '18

12 Dec '18

Hi, I did not parse your particular needs correctly with regard to complex step derivatives. I do not see any huge barriers, but it needs to be made clear the optimization methods only use the real parts of both the inputs and outputs (and if the user functions use the imaginary parts when computing their objective, that is, they really have a problems with complex variables, then they will get incorrect behavior). I am sure they will be other issues that crop up, such as only performing the KSP solves using the real part of the matrices. Maybe someone has a better idea about using complex step for derivatives of what is fundamentally a real valued problem. Todd. > On Dec 12, 2018, at 11:04 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > My problems are all real. > > I was just building a complex version of petsc and noticed these issue. As far as it is made clear (as it is) that Tao only supports real valued objective functions, there's no need to disable the solvers suite when petsc is compiled with complexes, since all the vectors and matrices used in TAO solvers will be zero in their imaginary part. But probably there are other issues that I'm not considering? > > Il giorno Mer 12 Dic 2018, 18:46 Munson, Todd <tmunson(a)mcs.anl.gov> ha scritto: > > Yes; the optimization problems do not make sense if the objective function is > from C^n to C, as there is not a natural ordering for complex numbers. If > your objective is from C^n to R (and the constraints are from C^n to R^m), > then the problem can be well defined. Then we need to get into what bound > constraints mean, etc. > > One challenge from the optimization perspective is dealing with the complex > vectors and creating complex Hessian approximations. I think its possible, > but has never been a priority. If the bounds are on the magnitude of the > complex values, then we need appropriate nonlinear constraints to enforce > them. > > Todd. > > > On Dec 12, 2018, at 9:18 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > > > > > > > Il giorno mer 12 dic 2018 alle ore 18:06 Dener, Alp <adener(a)anl.gov> ha scritto: > > Hi Stefano, > > > > I can’t really speak to why the entirety of TAO is disabled in complex builds. Todd can probably offer historical insight to the reason(s). > > > > However, we do have some methods in TAO that are not tested or guaranteed to be correct for complex-valued objective functions. > > > > As far as I understands, TAO is clear in requiring real objective functions, having PetscReal on the prototype for the callback > > > > The limited-memory quasi-Newton codes, for instance, currently only construct the approximate Hessian for the real part of the function and do not generate step directions in the complex part. I also don’t know whether any of the CG methods or line searches require any modifications to be correct in complex builds either. > > > > In your itemized list, I agree that at minimum we should be supporting #3 even if TAO itself does not work correctly for complex-valued functions. > > > > In the meantime, TAO can test real gradients or Hessians internally with `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call `TaoTestHessian()` too. It’s a finite-difference test though, and not a complex-step test. > > > > —— > > Alp Dener > > Argonne National Laboratory > > https://www.anl.gov/profile/alp-dener > > > > > >> On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > >> > >> If I compile PETSc with complex support, all of the TAO methods are not registered. > >> Fare enough? not really, I can imagine at least three valid reasons to use those > >> > >> 1) I want to check that my code works for complex builds, even if I have pure real function evaluations. I may need complex support in other parts or the code (not when using TAO), or I just want to be a diligent PETSc developer > >> 2) I want to test REAL gradients or Hessians using built-in capability, instead of writing my own > >> 3) I want to use the complex differentiation trick to compute REAL gradients > >> > >> Last time I checked, at least option 2) was available; However, from commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are registered when PETSC_USE_COMPLEX is defined, and code like the one below fail at runtime: > >> > >> TaoCreate() > >> TaoSetFromOption() > >> TaoSetObjectiveRoutine() > >> TaoTestGradient() > >> > >> [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing package: http://www.mcs.anl.gov/petsc/documentation/installation.html#external > >> [0]PETSC ERROR: Unable to find requested Tao type lmvm > >> > >> > >> -- > >> Stefano > > > > > > > > -- > > Stefano >

1 0

Re: [petsc-dev] Tao unusable from complex??
by Stefano Zampini 12 Dec '18

12 Dec '18

Il giorno Mer 12 Dic 2018, 20:04 Stefano Zampini <stefano.zampini(a)gmail.com> ha scritto: > My problems are all real. > And my mental issues all imaginary.... > I was just building a complex version of petsc and noticed these issue. As > far as it is made clear (as it is) that Tao only supports real valued > objective functions, there's no need to disable the solvers suite when > petsc is compiled with complexes, since all the vectors and matrices used > in TAO solvers will be zero in their imaginary part. But probably there > are other issues that I'm not considering? > > Il giorno Mer 12 Dic 2018, 18:46 Munson, Todd <tmunson(a)mcs.anl.gov> ha > scritto: > >> >> Yes; the optimization problems do not make sense if the objective >> function is >> from C^n to C, as there is not a natural ordering for complex numbers. If >> your objective is from C^n to R (and the constraints are from C^n to >> R^m), >> then the problem can be well defined. Then we need to get into what bound >> constraints mean, etc. >> >> One challenge from the optimization perspective is dealing with the >> complex >> vectors and creating complex Hessian approximations. I think its >> possible, >> but has never been a priority. If the bounds are on the magnitude of the >> complex values, then we need appropriate nonlinear constraints to enforce >> them. >> >> Todd. >> >> > On Dec 12, 2018, at 9:18 AM, Stefano Zampini via petsc-dev < >> petsc-dev(a)mcs.anl.gov> wrote: >> > >> > >> > >> > Il giorno mer 12 dic 2018 alle ore 18:06 Dener, Alp <adener(a)anl.gov> >> ha scritto: >> > Hi Stefano, >> > >> > I can’t really speak to why the entirety of TAO is disabled in complex >> builds. Todd can probably offer historical insight to the reason(s). >> > >> > However, we do have some methods in TAO that are not tested or >> guaranteed to be correct for complex-valued objective functions. >> > >> > As far as I understands, TAO is clear in requiring real objective >> functions, having PetscReal on the prototype for the callback >> > >> > The limited-memory quasi-Newton codes, for instance, currently only >> construct the approximate Hessian for the real part of the function and do >> not generate step directions in the complex part. I also don’t know whether >> any of the CG methods or line searches require any modifications to be >> correct in complex builds either. >> > >> > In your itemized list, I agree that at minimum we should be supporting >> #3 even if TAO itself does not work correctly for complex-valued functions. >> > >> > In the meantime, TAO can test real gradients or Hessians internally >> with `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call >> `TaoTestHessian()` too. It’s a finite-difference test though, and not a >> complex-step test. >> > >> > —— >> > Alp Dener >> > Argonne National Laboratory >> > https://www.anl.gov/profile/alp-dener >> > >> > >> >> On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev < >> petsc-dev(a)mcs.anl.gov> wrote: >> >> >> >> If I compile PETSc with complex support, all of the TAO methods are >> not registered. >> >> Fare enough? not really, I can imagine at least three valid reasons to >> use those >> >> >> >> 1) I want to check that my code works for complex builds, even if I >> have pure real function evaluations. I may need complex support in other >> parts or the code (not when using TAO), or I just want to be a diligent >> PETSc developer >> >> 2) I want to test REAL gradients or Hessians using built-in >> capability, instead of writing my own >> >> 3) I want to use the complex differentiation trick to compute REAL >> gradients >> >> >> >> Last time I checked, at least option 2) was available; However, from >> commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are >> registered when PETSC_USE_COMPLEX is defined, and code like the one below >> fail at runtime: >> >> >> >> TaoCreate() >> >> TaoSetFromOption() >> >> TaoSetObjectiveRoutine() >> >> TaoTestGradient() >> >> >> >> [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing >> package: >> http://www.mcs.anl.gov/petsc/documentation/installation.html#external >> >> [0]PETSC ERROR: Unable to find requested Tao type lmvm >> >> >> >> >> >> -- >> >> Stefano >> > >> > >> > >> > -- >> > Stefano >> >>

1 0

Re: [petsc-dev] Tao unusable from complex??
by Stefano Zampini 12 Dec '18

12 Dec '18

My problems are all real. I was just building a complex version of petsc and noticed these issue. As far as it is made clear (as it is) that Tao only supports real valued objective functions, there's no need to disable the solvers suite when petsc is compiled with complexes, since all the vectors and matrices used in TAO solvers will be zero in their imaginary part. But probably there are other issues that I'm not considering? Il giorno Mer 12 Dic 2018, 18:46 Munson, Todd <tmunson(a)mcs.anl.gov> ha scritto: > > Yes; the optimization problems do not make sense if the objective function > is > from C^n to C, as there is not a natural ordering for complex numbers. If > your objective is from C^n to R (and the constraints are from C^n to R^m), > then the problem can be well defined. Then we need to get into what bound > constraints mean, etc. > > One challenge from the optimization perspective is dealing with the complex > vectors and creating complex Hessian approximations. I think its possible, > but has never been a priority. If the bounds are on the magnitude of the > complex values, then we need appropriate nonlinear constraints to enforce > them. > > Todd. > > > On Dec 12, 2018, at 9:18 AM, Stefano Zampini via petsc-dev < > petsc-dev(a)mcs.anl.gov> wrote: > > > > > > > > Il giorno mer 12 dic 2018 alle ore 18:06 Dener, Alp <adener(a)anl.gov> ha > scritto: > > Hi Stefano, > > > > I can’t really speak to why the entirety of TAO is disabled in complex > builds. Todd can probably offer historical insight to the reason(s). > > > > However, we do have some methods in TAO that are not tested or > guaranteed to be correct for complex-valued objective functions. > > > > As far as I understands, TAO is clear in requiring real objective > functions, having PetscReal on the prototype for the callback > > > > The limited-memory quasi-Newton codes, for instance, currently only > construct the approximate Hessian for the real part of the function and do > not generate step directions in the complex part. I also don’t know whether > any of the CG methods or line searches require any modifications to be > correct in complex builds either. > > > > In your itemized list, I agree that at minimum we should be supporting > #3 even if TAO itself does not work correctly for complex-valued functions. > > > > In the meantime, TAO can test real gradients or Hessians internally with > `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call > `TaoTestHessian()` too. It’s a finite-difference test though, and not a > complex-step test. > > > > —— > > Alp Dener > > Argonne National Laboratory > > https://www.anl.gov/profile/alp-dener > > > > > >> On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev < > petsc-dev(a)mcs.anl.gov> wrote: > >> > >> If I compile PETSc with complex support, all of the TAO methods are not > registered. > >> Fare enough? not really, I can imagine at least three valid reasons to > use those > >> > >> 1) I want to check that my code works for complex builds, even if I > have pure real function evaluations. I may need complex support in other > parts or the code (not when using TAO), or I just want to be a diligent > PETSc developer > >> 2) I want to test REAL gradients or Hessians using built-in capability, > instead of writing my own > >> 3) I want to use the complex differentiation trick to compute REAL > gradients > >> > >> Last time I checked, at least option 2) was available; However, from > commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are > registered when PETSC_USE_COMPLEX is defined, and code like the one below > fail at runtime: > >> > >> TaoCreate() > >> TaoSetFromOption() > >> TaoSetObjectiveRoutine() > >> TaoTestGradient() > >> > >> [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing > package: > http://www.mcs.anl.gov/petsc/documentation/installation.html#external > >> [0]PETSC ERROR: Unable to find requested Tao type lmvm > >> > >> > >> -- > >> Stefano > > > > > > > > -- > > Stefano > >

1 0

Re: [petsc-dev] Tao unusable from complex??
by Munson, Todd 12 Dec '18

12 Dec '18

Yes; the optimization problems do not make sense if the objective function is from C^n to C, as there is not a natural ordering for complex numbers. If your objective is from C^n to R (and the constraints are from C^n to R^m), then the problem can be well defined. Then we need to get into what bound constraints mean, etc. One challenge from the optimization perspective is dealing with the complex vectors and creating complex Hessian approximations. I think its possible, but has never been a priority. If the bounds are on the magnitude of the complex values, then we need appropriate nonlinear constraints to enforce them. Todd. > On Dec 12, 2018, at 9:18 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > > > Il giorno mer 12 dic 2018 alle ore 18:06 Dener, Alp <adener(a)anl.gov> ha scritto: > Hi Stefano, > > I can’t really speak to why the entirety of TAO is disabled in complex builds. Todd can probably offer historical insight to the reason(s). > > However, we do have some methods in TAO that are not tested or guaranteed to be correct for complex-valued objective functions. > > As far as I understands, TAO is clear in requiring real objective functions, having PetscReal on the prototype for the callback > > The limited-memory quasi-Newton codes, for instance, currently only construct the approximate Hessian for the real part of the function and do not generate step directions in the complex part. I also don’t know whether any of the CG methods or line searches require any modifications to be correct in complex builds either. > > In your itemized list, I agree that at minimum we should be supporting #3 even if TAO itself does not work correctly for complex-valued functions. > > In the meantime, TAO can test real gradients or Hessians internally with `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call `TaoTestHessian()` too. It’s a finite-difference test though, and not a complex-step test. > > —— > Alp Dener > Argonne National Laboratory > https://www.anl.gov/profile/alp-dener > > >> On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: >> >> If I compile PETSc with complex support, all of the TAO methods are not registered. >> Fare enough? not really, I can imagine at least three valid reasons to use those >> >> 1) I want to check that my code works for complex builds, even if I have pure real function evaluations. I may need complex support in other parts or the code (not when using TAO), or I just want to be a diligent PETSc developer >> 2) I want to test REAL gradients or Hessians using built-in capability, instead of writing my own >> 3) I want to use the complex differentiation trick to compute REAL gradients >> >> Last time I checked, at least option 2) was available; However, from commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are registered when PETSC_USE_COMPLEX is defined, and code like the one below fail at runtime: >> >> TaoCreate() >> TaoSetFromOption() >> TaoSetObjectiveRoutine() >> TaoTestGradient() >> >> [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing package: http://www.mcs.anl.gov/petsc/documentation/installation.html#external >> [0]PETSC ERROR: Unable to find requested Tao type lmvm >> >> >> -- >> Stefano > > > > -- > Stefano

1 0

Re: [petsc-dev] Tao unusable from complex??
by Stefano Zampini 12 Dec '18

12 Dec '18

Il giorno mer 12 dic 2018 alle ore 18:06 Dener, Alp <adener(a)anl.gov> ha scritto: > Hi Stefano, > > I can’t really speak to why the entirety of TAO is disabled in complex > builds. Todd can probably offer historical insight to the reason(s). > > However, we do have some methods in TAO that are not tested or guaranteed > to be correct for complex-valued objective functions. > As far as I understands, TAO is clear in requiring real objective functions, having PetscReal on the prototype for the callback The limited-memory quasi-Newton codes, for instance, currently only > construct the approximate Hessian for the real part of the function and do > not generate step directions in the complex part. I also don’t know whether > any of the CG methods or line searches require any modifications to be > correct in complex builds either. > > In your itemized list, I agree that at minimum we should be supporting #3 > even if TAO itself does not work correctly for complex-valued functions. > > In the meantime, TAO can test real gradients or Hessians internally with > `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call > `TaoTestHessian()` too. It’s a finite-difference test though, and not a > complex-step test. > > —— > *Alp Dener* > Argonne National Laboratory > https://www.anl.gov/profile/alp-dener > > > On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev < > petsc-dev(a)mcs.anl.gov> wrote: > > If I compile PETSc with complex support, all of the TAO methods are not > registered. > Fare enough? not really, I can imagine at least three valid reasons to use > those > > 1) I want to check that my code works for complex builds, even if I have > pure real function evaluations. I may need complex support in other parts > or the code (not when using TAO), or I just want to be a diligent PETSc > developer > 2) I want to test REAL gradients or Hessians using built-in capability, > instead of writing my own > 3) I want to use the complex differentiation trick to compute REAL > gradients > > Last time I checked, at least option 2) was available; However, from > commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are > registered when PETSC_USE_COMPLEX is defined, and code like the one below > fail at runtime: > > TaoCreate() > TaoSetFromOption() > TaoSetObjectiveRoutine() > TaoTestGradient() > > [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing package: > http://www.mcs.anl.gov/petsc/documentation/installation.html#external > [0]PETSC ERROR: Unable to find requested Tao type lmvm > > > -- > Stefano > > > -- Stefano

1 0

Re: [petsc-dev] Tao unusable from complex??
by Dener, Alp 12 Dec '18

12 Dec '18

Hi Stefano, I can’t really speak to why the entirety of TAO is disabled in complex builds. Todd can probably offer historical insight to the reason(s). However, we do have some methods in TAO that are not tested or guaranteed to be correct for complex-valued objective functions. The limited-memory quasi-Newton codes, for instance, currently only construct the approximate Hessian for the real part of the function and do not generate step directions in the complex part. I also don’t know whether any of the CG methods or line searches require any modifications to be correct in complex builds either. In your itemized list, I agree that at minimum we should be supporting #3 even if TAO itself does not work correctly for complex-valued functions. In the meantime, TAO can test real gradients or Hessians internally with `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call `TaoTestHessian()` too. It’s a finite-difference test though, and not a complex-step test. —— Alp Dener Argonne National Laboratory https://www.anl.gov/profile/alp-dener On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov<mailto:[email protected]>> wrote: If I compile PETSc with complex support, all of the TAO methods are not registered. Fare enough? not really, I can imagine at least three valid reasons to use those 1) I want to check that my code works for complex builds, even if I have pure real function evaluations. I may need complex support in other parts or the code (not when using TAO), or I just want to be a diligent PETSc developer 2) I want to test REAL gradients or Hessians using built-in capability, instead of writing my own 3) I want to use the complex differentiation trick to compute REAL gradients Last time I checked, at least option 2) was available; However, from commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are registered when PETSC_USE_COMPLEX is defined, and code like the one below fail at runtime: TaoCreate() TaoSetFromOption() TaoSetObjectiveRoutine() TaoTestGradient() [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing package: http://www.mcs.anl.gov/petsc/documentation/installation.html#external [0]PETSC ERROR: Unable to find requested Tao type lmvm -- Stefano

1 0